Komische Zeitverzögerung bei VISA write Parallelport

Moin.
Ich habe ein Programm geschrieben, welches durch den "Visa write"-Befehl Markersignale an einen EEG-Verstärker schickt (Diese werden dann von der EEG-Software in eine Datei geschrieben); nachdem ich mir die ersten Daten des EEG-Verstärkers angesehen habe ist mir aber eine ungewöhnliche zeitliche Verzögerung aufgefallen.

Mein Programm schickt nacheinander zwei Marker an den Verstärker.
Der zeitliche Abstand zwischen den Markern sollte 150ms, 350ms, 750ms oder 1500ms betragen (Wie lang der Abstand ist entscheidet ein Zufallsgenerator der eine case-Struktur schaltet).

Mein Problem ist jetzt, dass dieser Ablauf nur für 350ms, 750ms und 1500ms funktioniert. In der 150ms Bedingung ist der Abstand zwischen den Markern irgendweswegen 200ms.
Noch verwirrender wird es für mich, da alle vier Abstände exakt gleich funktionieren...Einziger Unterschied sind die Eingaben für die "wait"-Funktion (Ein Bild vom Skript ist im Anhang).

Hat jemand eine Idee woher dieses veränderte Timing kommen kann? Ist der Parallelport irgendweswegen für 200ms beschäftigt?



Grüße
Philipp Dehmel

Anzeige

Hallo dehmelp,

Zitat:Mein Programm schickt nacheinander zwei Marker an den Verstärker. Der zeitliche Abstand zwischen den Markern sollte 150ms, 350ms, 750ms oder 1500ms betragen

- Du liest da zweimal ein JPG aus einer Datei und stellst das dar. Bist du dir sicher, dass das jedesmal in weniger als 100ms erledigt ist?
- Du schickst da Befehle per VISAWrite ab. Wer sagt dir, dass dieser Befehl sofort beim Gerät ankommt? Da sind noch einige Treiberschichten dazwischen!
- Wie lange benötigt dein Gerät selbst, um den empfangenen Befehl zu verarbeiten?

Tipp:
- Verwende doch FormatIntoString, um deinen Befehl zu erstellen: nur eine Funktion statt gleich 3…
- Musst du wirklich einen DBL-Wert an deinen Case-Selektor verdrahten?

Hallo Gerd,
vielen Dank schonmal für die schnellen Kommentare.

Ich bin mir unsicher wie schnell der Computer es schafft die Bilder einzulesen und zu zeichnen, aber vermutlich schafft er es... Die Bilder sind im Schnitt 22kB groß.
Ist das (deiner Erfahrung nach) klein genug für eine Darstellung in unter 100ms?

Der EEG-Verstärker selbst ließt durchgehend (Pollingrate von über 1000Hz) den Parallelport aus... Ohne weitere Verarbeitung schreibt die Software dann einen Zahlenwert (Basierend auf der Kombination aktiver Parallelport-Pins) in eine Datei. Hier sollte also auch eigentlich keine Verzögerung stattfinden.

Deine Idee mit den zwischengeschalteten Treiberschichten ist auf jeden Fall möglich, allerdings habe ich keine Ahnung wie ich solch ein Delay messen sollte. Zusätzlich wüsste ich aktuell nicht wieso solch eine Problematik sich nur auf die schnellste Bedingung auswirken sollte...Müsste das Problem dann nicht in allen Bedingungen auftreten? Und liegt ein Delay von 50ms, erzeugt durch die Treiberschichten, in einem realistischen Rahmen? (Ich hoffen bei solchen Fragen immer auf eure Erfahrungswerte. )

Eine Sache die ich noch erwähnen kann; Es gibt leichte Schwankungen in der Intervalldauer zwischen den Markern. (Bei 350ms irgendwas zwischen 349ms und 351ms, bei 750ms irgendwas zwischen 749ms und 751ms, bei 1500ms irgendwas zwischen 1499ms und 1501ms........Nur bei der 150ms Bedingung sind die Schwankungen höher (und der Wert falsch), irgendwas zwischen 190ms und 215ms).




Zu deinen Tipps...
Ich schaffe es mit LabView Skripte zum laufen zu bekommen, habe es aber nie gelernt... :/
Daher sehen meine Skripte auch (noch) sehr hässlich aus, werden aber von Tipp zu Tipp schöner.

Hallo dehmelp,

Zitat:Es gibt leichte Schwankungen in der Intervalldauer zwischen den Markern.

Dein Programm läuft (sehr wahrscheinlich) unter Windows. Und das ist kein RT-System!
Niemand garantiert dir unter Windows eine zeitliche (Software-)Genauigkeit von 1ms…
Wenn du so etwas erreichen willst, musst du entweder ein RT-System wie ein cRIO nehmen oder eine Hardware suchen, die mit ihrem eigenen Takt arbeitet.

Zitat:Die Bilder sind im Schnitt 22kB groß. Ist das (deiner Erfahrung nach) klein genug für eine Darstellung in unter 100ms?

Ich kenne deinen Rechner nicht. Ein kleiner Celeron/Atom benötigt vielleicht mehr Zeit als ein nagelneuer i7-8xxx oder Xeon.
Ich kenne auch deine Bildgröße (in Pixeln) nicht. Ein 4k-Bild (4096×2048) benötigt mehr Handling als ein VGA-Bild (640×480) - und LabVIEW macht aus deinen 22kB Dateigröße eben "reine" Bilddaten…
Ich kenne auch nicht den Speicherort der Dateien. Hast du eine SSD? Oder eine alte Festplatte? Oder liest du von einem Server am anderen Ende der Republik?

Zitat:Ich schaffe es mit LabView Skripte zum laufen zu bekommen, habe es aber nie gelernt... :/

Das sind keine "Skripte", sondern Blockdiagramme. Auch sowas (die korrekten Bezeichnungen) lernt man in den Einsteigerkurse, die sich hinter den Links in meiner Signatur verbergen…

Zitat:Basierend auf der Kombination aktiver Parallelport-Pins

Du hast noch einen Parallelport am Rechner?

Hallo Gerd,
die Kurse hinter deiner Signatur sehen super aus, da werde ich wohl mal ein bisschen stöbern.

Das Windows nicht RT genau ist wusste ich, aber wenn Cheffe das System nutzen will bekommt er es halt. :/
Eine Genauigkeit von +-2 oder 3ms ist für meine Zwecke ausreichend, 50ms allerdings nicht.

Vom Rechner her habe ich einen i5-4590; 4GB Arbeitsspeicher; 32Bit System und keine SSD-Festplatte.
Die Bildgröße sind 1280*1024Pixel; 84dpi.

Und jaaaaa, ich muss noch einen Parallelport nutzen. (Nachgerüstet über eine PCIe-Karte)


Du siehst schon, alles ziemlich chaotisch in diesem Projekt...
Ich soll halt ohne Ausbildung, Gelder oder Zeit ein Blockdiagramm schreiben. Super Idee!!!

Grüße
Philipp

Hallo dehmelp,

wenn du zeitlich sehr genau 8 Bits/Leitungen setzen willst, kann ich dir Hardware von NI empfehlen. Die kommt mit dem DAQmx-Treiber, der sehr einfach zu handhaben ist.

Such dir ein Gerät, dass mindestens 8 DOs bietet und diese per Hardware-Timing betrieben kann (NI in München berät dich dazu, einfach mal 089-7413130 anrufen). Dann kannst du nämlich einfach eine (digitale) Waveform erstellen, die dann mit dem festen Hardwaretakt zumindesten mikrosekundengenau abgespielt wird. Das sollte für dein Gerät reichen…

Anzeige

Hi Gerd,
danke für deine Hilfe!
Deine Denkanstöße haben sehr geholfen den Fehler zu finden...Und für mein nächstes Projekt absolvier ich vorher einen Kurs aus deiner Signatur.


Der Fehler ist tatsächlich die Geschwindigkeit beim laden der .jpg. Mein Computer schafft es nicht Bilder in unter 50ms (zumindest in etwa) zu laden.

Benötigte Zeiten zum laden der unterschiedlichen Grafiken sind:

3*3 Pixel; 737 Byte; ca 33ms benötigte Ladezeit.
1280*1024 Pixel; 22,7 kB; ca 70ms benötigte Ladezeit.
4096*2160 Pixel; 135 kB; ca 800ms benötigte Ladezeit.

Vielleicht helfen diese Richtwerte ja auch anderen....

Grüße
Philipp

Hallo dehmelp,

das Problem ist hier, dass aus den 22kB JPG eben 1280*1024*3~=4MB Byte gemacht werden, die dann in den PictureIndicator geschoben werden.

- Das Laden der Daten kannst du ja außerhalb der Sequenz erledigen (muss ja nur einmal geschehen)…
- Wenn die Bilddaten vorher feststehen, könntest du auch einen PictRing verwenden…

Hi Gerd,
die Daten außerhalb der Sequenz zu laden war jetzt auch meine Idee...Beim nächsten Blockdiagramm wird es so passieren.

Den PictRing kenn ich noch nicht, aber das sehe ich mir jetzt an.

Grüße
Philipp