ABACOM - ELECTRONIC SOFTWARE

Hallo liebe Fan Gemeinde von Profilab,

ich benutze Profilab nun schon länger als 2 Jahre und ich arbeite sehr gerne damit! Leider habe ich Probleme mit der Ausführgeschwindigkeit, die ich nicht verstehen kann. Da ich hierüber nichts in der Suche gefunden habe, nehme ich an, das das Problem bei mir liegen muss?!
D.h. das Programm läuft langsam bis sehr langsam obwohl die Prozessorlast bei weitem nicht an die 100% kommt. Ich habe als Beispiel einen Datenlogger angehängt - hier kann man beim Frontplatten umschalten schon deutlich die beginnende Verlangsamung sehen (je nach Rechner Power! ). Fügt man noch einige Diagramme und Anzeigen hinzu wird es dann immer deutlicher langsamer...

Gerne füge ich bei Bedarf noch weitere (drastisch langsamere) Programme bei.

Hat jemand dasselbe Problem oder eine Idee was ich ändern sollte?

Gruß
HR

Dieses kleine Windowshäkchen wegzunehmen bewirkt wahre Wunder!

Eine neue Version von ProfiLab wäre eigentlich die vernünftigere Alternative.
Warum soll man erst sein System verbiegen, damit etwas vernünftig läuft?

Wann kommt denn mal was neues?
Die Version 4 ist 7 Jahre alt.

Hallo,

vielen Dank für den TIP - ich habe diesen ausprobiert - mit recht wenig Erfolg

Das Problem besteht auch unter WinXP. In der Entwicklungsumgebung läuft das Programm dann teilweise nur mit ca. 30 Hz (egal ob slow oder fast) oder weniger - die Prozessorlast liegt aber nie über 30% (egal ob P4 oder Core i5, wobei das programm bei Core i5 erheblich schneller arbeitet).

Vielleicht hat noch jemand eine andere Idee, bzw. kann erklären wo die Rechenpower verpufft?

Danke!
Gruß
HR

Hi,
hast Du die Systemressourcen schon geprüft für die Prozesse, welche nebst PL auf Deinem PC gestartet sind ?

Im Taskmanager unter Prozesse den entsprechenden Prozess anclicken, rechte Maustaste, Priorität
Versuch auch mal, PL höhere Priorität zuzuteilen.

Gruss Thomas

Hallo,

vielen Dank auch für diesen Tip! - werde ich mal verfolgen - auf meinem Rechner (core i7) ist jedoch (leider) kein spürbarer Unterschied zu verzeichnen.

Aber - nach Durchsicht von wesentlich älteren - sehr ähnlich aufgebauten Projekten fällt auf, das diese wesentlich schneller laufen, ich habe mal eins angehängt...

@abacom: vielleicht haben Sie dazu eine (weitere) Idee?

Danke!
Gruß
HR

...und bin für jede weitere Anregung zu haben!

Hi,
ohne Treiber erreicht mein Uralt XP-LapTop für fast 750Hz und für slow 300 und etwas.

Könnte der Treiber Ursache fürs Ausbremsen sein ?

Kann ich mir gut vorstellen. Um was handelt es sich denn ?

Gruss Thomas

Hallo,

bei diesen Projekten ist jeweils ein Redlab Temp und ein Meilhaus U12 verbaut. Die Treiberversionen werde ich nächste Woche mal checken, bzw. die alten Programme auf den gleichen Rechnern ausprobieren (habe da vom P4 bis zum core i7 alles dabei )

unter Vorbehalt: - seit Aufruf der "alten" Projekte scheinen die neuesten auch schneller zu laufen - ich werde dies aber erst einmal ausführlich testen und dann berichten

Gruß
HR

Hallo,

folgende Resultate haben sich ergeben:

Durch Laden eines älteren Projektes verändert sich die Ausführgeschwindigkeit nicht!

Aber: wird das Projekt (leider kann ich dies nicht anhängen, da das Projekt 310 Kb gross ist und nur 256 Kb erlaubt sind...) mit "fast" gestartet, liegt die Ausführgeschwindigkeit bei ca. 36 Hz - wird dann auf "slow" geschaltet, liegt diese bei ca. 32 Hz, schaltet man dann auf "fast" zurück, ergibt sich eine Ausführgeschwindigkeit von ca. 700 Hz (Umschalten bei laufendem Projekt) - dieser Effekt ist definitiv reproduzierbar!
Schaltet man danach zwischen "fast" und "slow" ergeben sich Durchschnittswerte!?.....

Auch bei anderen Projekten ist dieser "Umschalteffekt" zu beobachten.

(Werte ermittelt auf einem Core i5 mit 2,8 Ghz und 4 Gb Ram, Win 7 64 bit)

Gruß
HR

@Abacom

Dieses kleine Windowshäkchen wegzunehmen bewirkt wahre Wunder!

scheint mir eine Ausrede zu sein, da bei meinem System sowieso "optimieren für performance" eingestellt ist, was bewirkt, dass 'unten' alle Häkchen "draussen" sind.
Das Problem (wie beschrieben), ist jedoch auch dann vorhanden!

Habe folgendes festgestellt (beim laden von hradke's .prj):
PLE geht auf ROT (in ressource monitor) ein rechtsklick 'drauf' zeigt folgendes:
(siehe screenshot unten), dies scheint ein Debugger-Aufruf zu sein, der PLE solange blockiert bis er (der Aufruf) in ein Timeout gerät (dauert lange!!), um danach PLE wieder die Kontrolle zurück gibt (danach geht es schnell).
Weitere info zu DWM.exe bei Microsoft:
http://msdn.microsoft.com/en-us/library ... 85%29.aspx
Ist es möglich, dass beim kompilieren die 'debug' Option eingestellt war?
Bin hier wirklich nur am spekulieren! Dies könnte zur Folge haben, dass beim Entwickler alles I.O. ist 'da Debugger installiert', bei allen 'anderen' jedoch ein Problem entsteht 'da KEIN Debugger vorhanden' ?!?!)

1.) @IKT: Dass gutgemeinte Tipps hier als Ausrede bewertet werden scheint mir unangemessen.
2.) RedLab- und LabJack-Treiber sind leider ziemliche Bremsen, da diese komplexe Protokolle
mit viel Overhead und langen Antwortzeiten verwenden. Dass ein solch Projekte dann
evtl. nur noch mit wenigen Hz arbeitet ist kein Fehler sondern eine Tatsache.

Hallo @alle & Abacom,

zu 1) von Abacom: bin der Meinung, dass in eine völlig falsche Richtung gesucht wird da:
a) NICHT die Taktrate der Abarbeitung dass Problem ist, sondern die
b) 'unmöglich' lange Ladezeit (egal ob Simulation/kompiliertes PRJ)
wie meine beschriebene Untersuchung zeigt.
zu 2)

LabJack-Treiber sind leider ziemliche Bremsen, da diese komplexe Protokolle
mit viel Overhead und langen Antwortzeiten verwenden

a) 'komplexe Protokolle' = 100% einverstanden.
b) 'lange Antwortzeiten' = 20 mS, je Aufruf einer Funktion, Angabe LabJack Programmierhandbuch ("Windows typisch = 16 mS"), ist auch im C-Headerfile so beschrieben.
Da ich gerade (die letzten paar Tage) dabei bin, die 'ljackuw.dll' Anbindung von C nach BASIC zu konvertieren, kenne ich diese 'Interna' ziemlich gut. Daraus ergibt sich:
2 x AISample + 1 x DigitalIO + 1 x AOUpdate (diese 4 Aufrufe 'bedienen' alle IO's , die in PL unterstützt werden, incl. LED und reset Counter) = max. 80 mS.
Dies ergibt jedoch noch immer genügend Simulationsgeschwindigkeit in PL ('slow' Modus), entsprechende HW vorausgesetzt. Aber noch einmal:

DIE LADEZEITEN SIND IM MOMENT UNZUMUTBAR LANGE !

Die von mir eingesetzte HW/OS Kombination: Win8 pro 64, i7, 8 GB RAM, SSD, will heissen: an der HW kann's nicht liegen.

... und gerade bei den Ladezeiten schafft die bereits oben erwähnte Deaktivierung der Windows-Desktopgestaltung Abhilfe.

Hallo an alle & Abacom,
nur damit alle auf dem gleichen Stand der Informationen sind. Meine gegenwärtigen (vergangenen/zukünftigen etc.) Einstellungen sind wie auf dem folgenen 'Screen-Shot':

... oben erwähnte Deaktivierung der Windows-Desktopgestaltung Abhilfe.

Würde es vielleicht ... unter der Voraussetztung, dass es jemals 'aktiviert' war. Dies jedoch war (bei meinem Gerät) noch nie der Fall, da ich von vornherein auf M$'s 'Verzierungen' verzichte (ziehe eine schnelle Maschine vor).
Habe die Hoffnung noch nicht ganz aufgegeben, dass von nun an, an richtiger Stelle nach Ursachen für die elendiglich langen Startzeiten gesucht wird.

Bitte auch mal hier nachsehen
viewtopic.php?f=21&t=2829&p=8967&hilit= ... tung#p8967

Man muss übrigens nicht gleich sein ganzes System verbiegen, es reicht auf die Profilab Verknüpfung zu gehen, rechte Maustaste, anschließend unter Kompatibilität Einstellungen wie im Bild.

Hallo,

leider scheint das Thema wieder versiegt zu sein ... - nimmt man wie von IKT im letzten Beitrag gezeigt, den Haken bei "Skalierung bei hohem DPI-Wert deaktivieren" heraus, so bewirkt das - komischerweise nur bei einigen Systemen - wahre Wunder, allerdings selbst dann immer noch viel zu lang.

Eigenartigerweise ist der erwartete Geschwindigkeitszuwachs von einem Pentium 4 System zu einem Core i7 System nicht wirklich zu beobachten - da frage ich mich nur an welcher Hardwareschraube muss ich denn drehen, damit das System schneller lädt/arbeitet?

Interessant ist auch, das egal wie viel Code ich ohne Anzeigeelemente schreibe (na jedenfalls fast... ) sich dies kaum auf die Ladezeiten auswirkt, sobald jedoch vermehrt Eingabefelder und Anzeigen hinzu kommen sich die Ladezeiten drastisch verlängern. Dies kann man man im Übrigen auch sehr schön nachvollziehen, wenn man einfach Eingabe/Anzeigefelder dupliziert (ohne irgendwelchen Code) und dann sich die Ausführungsrate anschaut...

Gruß
HR

Hallo HR,

Schaue dir mal mein Thema mit der " Auslastung Mehrkernprozessoren " an
Da hat die Trennung von Labjack Ue9 aus der Berechnung über TCP eine ca. 20 fache Geschwindigkeitssteigerung gebracht.

Vielleicht hilft es bei dir auch.

Gruß Heiko

Hallo,

vielen Dank für den Tip - sehr interessanter Ansatz, leider habe ich mit Profilab TCP Verbindungen in Verbindung mit Realview bisher schlechte Erfahrungen, was die Zuverlässigkeit des Aufbaus der Verbindungen betrifft - aber ich werde mir da mal was zusammen basteln

Gruß
HR

Hallo an alle und hrathke,

habe nun wie es scheint 'des Pudels Kern' herausgefunden:
1) je mehr grafische Elemente, desto länger die Ladezeit. (Ärgernis Nummer Eins!)
2) je häufiger grafische Elemente (Anzeigen) 'updated' werden (Frequenz) umso mehr geht die Simulationsfrequenz 'in die Knie'. (Ärgernis Nummer Zwei!)

Diese Tatsachen, gemeinsam betrachtet, deuten darauf hin, dass PL/PLE die grafische Aufbereitung selber erledigt, anstatt diesen Aufwand, per geeignetem Grafikkarten-Treiber, an die Grafikkarte (GPU) zu 'delegieren'.
Dies bedeutet für uns, dass die beste HW in diesem Fall absolut nichts bringt.