Velleman USB Board - IPS "übersieht" Impulse

Hallo,

ich versuche meinen Stromverbrauch über IPS zu erfassen. Dazu habe ich den Impulsausgang eines digitalen Stromzählers (800 Impulse/kWh) mit dem Digital-Eingang 1 des Velleman USB Boards verbunden. An diesem Eingang werden die Impulse auch vom Board gezählt und können über die Funktion VelleUSB_ReadCounter ausgelesen werden.
Im Startup-Script lese ich diesen Counter aus und speichere ihn in einer Variablen.
In IPS kann man dem Eingang eine Boolean-Variable zuweisen. Diese triggert einen Script, der die Counter-Variable bei jedem Impuls um eins hochzählt und die Boolean-Variable wieder auf „false“ setzt. Insgesamt würde ich erwarten, dass der Zähler des USB-Boards und der vom Script bediente Zähler synchron laufen. Wenn ich allerdings nach ein paar Minuten die beiden Zähler vergleiche, tauchen da recht grosse Differenzen auf (IPS-Zähler ist deutlich niedriger).
Wenn ich mich nun mit dem Rechner vor den Zähler setze (der zeigt seine Impulse über eine LED an) und im Debugfenster verfolge, wie oft der Script getriggert wird, kann man recht deutlich sehen, dass IPS nur „gelegentlich“ die Boolean-Variable korrekt ansteuert, obwohl nur alle 5-7 Sekunden ein Impuls kommt. Der Zähler des USB-Boards zählt hingegen alle Impulse korrekt mit.

Ich muss also davon ausgehen, dass die Strecke Stromzähler->USB-Board ok ist, denn der Zähler auf dem USB-Board und der Stromzähler laufen synchron. Die Übertragung vom USB-Board zum PC ist auch ok, denn die Velleman-Software zeigt die hereinkommenden Impulse an und die laufen ebenfalls synchron mit der LED des Stromzählers.
Bleibt noch IPS. Dort habe ich das Interface auf „Trigger High“ gestellt. Die Boolean-Variable wird auch wie erwartet (wenn IPS es denn wahrnimmt) gesetzt, bzw. aktualisiert. Beobachtet man das Variablenfenster und die Stromzähler-LED, fällt ebenfalls auf, dass die Boolean-Variable NICHT synchron mit der LED läuft, sondern den einen oder anderen Impuls nicht mitbekommt.
Da nicht allzu viele Impulse kommen, resultieren die Differenzen auch nicht aus irgendwelchen Überläufen (ca. alle 6 Sekunden ein Impuls = 10 Impulse/Minute = 600 Impulse/Stunde).

Im Startup-Script wird die Counter-Variable mit dem aktuellen Zählerstand des USB-Boards initialisiert :

SetValueInteger("AZ_IO_Counter", VelleUSB_ReadCounter(12345, 1));

Der OnUpdate-Trigger startet dann den Script zum Hochzählen (die Trigger-Variable ist Boolean und heisst „AZ_IO“:

SetValueInteger($IPS_VARIABLE."_Counter", GetValueInteger($IPS_VARIABLE."_Counter") + 1);

Eigentlich recht trivial - wenn nur AZ_IO bei jedem Impuls bedient werden würde <seufz>.

Habe ich etwas übersehen oder hat das Velleman-Modul in IPS da tatsächlich ein Problem ?

Grüsse
Uwe

Hallo Uwe,

einige zusätzliche Angaben wären noch hilfreich:

  1. Triggertyp (OnChange, OnUpdate, …)
  2. Ruhepegel (wenn kein Impuls ansteht, high oder low)
  3. Dauer eines Impulses

Gruß
HJH

Hallo HJH,

  1. Triggertyp (OnChange, OnUpdate, …)

wie im ersten Beitrag bereits geschrieben : „Der OnUpdate-Trigger…“

  1. Ruhepegel (wenn kein Impuls ansteht, high oder low)

Mit dem Multimeter messe ich 0.

  1. Dauer eines Impulses

Dazu bräuchte ich wohl ein Speicher-Oszi. Im Datenblatt des Zählers stehen >=30ms.

Grüsse

Uwe

Hallo Uwe,

in der Wiki-Beschreibung zum Vellemann-USB-Board steht, dass die Eingänge nur alle 100ms abgetatstet werden. Daraus folgt, dass Impulse, die kürzer als das Abtastintervall sind, nur durch Zufall erfasst werden.

Hier gibt es folgende Abhilfe:

  • dafür sorgen, dass die Impulse länger als 100ms dauern
  • andere Erfassungsmaßnahmen treffen

Eine Verlängerung der Impulse erfordert zusätzliche Hardware, ist also mit Aufwand verbunden.

Dagegen ist es einfacher bei der Erfassung einen anderen Weg einzuschlagen. Anstatt jeden Impuls einzeln zu zählen kannst Du auch (z.B. jede Minute, oder alle 15 Sekunden) den Zähler auslesen. Damit ist die zeitliche Auflösung nur geringfügig schlechter als bei der Einzelimpuls-Methode. Dafür ist das Ergebnis aber immer korrekt.

Gruß
HJH

Hallo HJH,

den Wiki kannte ich und nachdem ich die 30ms aus dem Datenblatt rausgesucht habe, dachte ich mir schon so etwas. Eine Zusatz-Hardware zur Impuls-Verlängerung wäre wohl etwas zu aufwendig. Das Problem liegt damit an IPS, denn die Velleman-Software schafft es ja problemlos, auch 30ms kurze Impulse anzuzeigen. Vielleicht sollte man die Abtastrate konfigurierbar machen.

Vielen Dank für Deine Tipps. Da bleibt dann als kurzfristige Lösung wohl nur die Nutzung des USB-Board-Zählers.

Grüsse

Uwe

30ms sind für einen Windows-PC zu kurz um nebenbei erkannt zu werden. Dafür muss man besondere, prozessorfressende, externe Threads erstellen. Wer so kurze Intervalle abfragen will/muss braucht dafür einen Industrie PC oder eine SPS. Im Einfachsten Fall einen Mikrocontroller vorschalten, der einen Windowsfreundlichen Impuls erzeugt. Es gibt für diesnen Zweck spezielle Linux-Varianten, die so abgespeckt sind, dass sie die Schnittstellen in derart kurzen Intervallen abfagen können. Mit „einstellen“ ist es also nicht getan…

Gruß,

Toni

Hallo,

einfach 'nen kleinen Mono-Flop vorschalten. Hach, träum die gute alte Schulzeit.

mfG Franz

Stimmt auch… Das Gute liegt oft so nah… :D:cool:

Toni

Ganz so kritisch kann es wohl nicht sein, da die Velleman-Software genau das schafft, ohne nennenswerte Prozessorlast zu erzeugen.

Momentan behelfe ich mir mit dem Zähler auf dem USB-Board, weil es die einfachere Lösung ist und das Board momentan mit der USB-Versorgung auskommt (also ohne zusätzliche Stromversorgung). Ein Mono-Flop als „Seh-Hilfe“ für IPS ist natürlich auch noch eine Option.

Vielen Dank für die Tipps

Uwe

Das ist doch Milchmädchenlogik… Wenn die Hauptaufgabe der Software eine andere wäre würd sie es auch nicht schaffen… und die Prozessorlast, die du in Windows in Prozent angezeigt bekommst ist wohl auch sehr stark von deinem Prozessor abhängig, meinst du nicht? :stuck_out_tongue:

Toni

Hallo Toni,

das hat mit Milchmädchenlogik nichts zu tun. Selbst mit durchschnittlich schnellen Rechnern kann man locker mehrere Dutzend Signale im 10ms-Takt messen, auf Platte schreiben und online auf den Bildschirm zeichnen. Da kommt dann ein 1,4-MHz-Laptop zu nennenswerten Prozessorlasten und der Lüfter hat ordentlich zu tun, aber es geht nix verloren.
Ein einzelnes Signal im 30ms-Takt abzutasten ist selbst für deutlich langsamere Rechner eher der Kategorie „Pippifax“ zuzuordnen.

Der im Windows-Taskmanager in Prozent angegebene Wert ist natürlich vom Prozessor abhängig (von was denn sonst ? :wink: ) und zeigt, dass „mein“ Prozessor sowohl von IPS, als auch von der Velleman-Software weitgehend unbeeindruckt bei <5% vor sich hinwerkelt. Auch wenn ich die Velleman-Instanz in IPS deaktiviere und die Karte mit der Velleman-Software auslese, während IPS weiterläuft, juckt das die CPU nicht mal ansatzweise.
Auch wenn ich nicht aus beruflichen Gründen wüsste, was mit einem PC „geht“, ist es eigentlich nicht einsichtig, warum IPS etwas nicht kann, was anderen Programmen offensichtlich nur wenig Mühe bereitet und sich meilenweit entfernt von den Leistungsgrenzen (m)eines PCs befindet.

Momentan bekomme ich das Problem mit dem karteninternen Impulszähler ja gelöst, würde aber trotzdem anregen, die Messrate parametrierbar zu machen. So kann jeder Benutzer nach Bedarf und zur Verfügung stehender Rechenpower seine Signale einlesen (im Zweifel auch ohne zusätzliche Schaltungsentwicklung und ohne Löten, was sicher viele Benutzer vor unlösbare Probleme stellt). IPS könnte die 100ms vorbelegen (oder sogar aufgrund der Taktfrequenz auf optimalere, aber sichere Messraten umstellen) und dem Benutzer trotzdem die Möglichkeit geben, kleinere Abtastraten einzustellen. Und das Risiko, dass der Benutzer seinen Rechner überfordert, besteht ja sowieso, indem er zu viele Instanzen definiert oder „ungeschickte“ Programme schreibt. Kein Grund also, sich bei der Messrate an dem langsamsten denkbaren Rechner zu orientieren.

Grüsse vom

Milchmädchen :smiley:

mehrere Dutzend Signale im 10ms-Takt messen

dass halte ich für ein Gerücht - oder seit wann ist Windows ein Echtzeit-System :confused:

Siehe auch "Round Robin Verfahren"

MST

Hallo MST,

das ist richtig. In der Fahrzeug-Meßtechnik umgehen unsere Systemlieferanten das Problem, indem sie die Meßwerte mit einem Zeitstempel versehen. Das ändert aber nichts an dem Umstand, das der PC aus den im 10ms-Takt einprasselnden Botschaften, die Messwerte aus der Botschaft pfriemeln, auf Platte schreiben und auf dem Bildschirm darstellen muss. Der Puffer der Hardware ist da nicht allzu gross und unsere Systeme laufen im Fahrzeug durchaus mehrere Stunden bzw. auf Prüfständen mehrere Tage oder Wochen.

Ohne jetzt Werbung machen zu wollen (der Hersteller der Meß-Hard- und Software ist Lieferant meines Brötchengebers), kannst Du Dir ja mal die technischen Daten anschauen : http://www.vector-worldwide.com/vi_can-lin_interfaces_de,2816.html

Konkret im Einsatz haben wir z.B. teilweise sogar zwei CAN-CARD-XL in einem PC. Die Hardware kann zwar bis zu 35.000 Botschaften/Sekunde empfangen, davon werden aber nur ausgewählte Botschaften an den PC durchgereicht, der daraus dann die Einzelsignale extrahiert, umrechnet und abspeichert. Bei kritischen Systemen (Motor, Getriebe, Fahrwerk, Airbag, usw.) werden dabei von mehreren Steuergeräten, jeweils mehrere Botschaften im 10ms- und 20ms-Takt übertragen. Der PC muss also pro 10ms-Takt mehrere Botschaften verarbeiten. Die Zeitstempel erzeugen dabei sogar noch einen Overhead, ermöglichen es aber, die Messwerte (echt-)zeitlich zuzuordnen.

Hochgenaue Messungen („Echtzeit“) sind mit dem PC sicher nicht möglich, aber Abtastraten von „ungefähr“ 10ms funktionieren einwandfrei, zumal beim Grundproblem ja „nur“ ein Bit (bzw. beim Velleman-USB-Board maximal 5 digitale Eingangs-Bits) erkannt werden müssen. Für die Stromverbrauchs-Messung (800 Impulse(kWh)) ist da nicht mal Durchsatz dahinter. Bei einer Last von 6000W würden 6x800 Impulse in einer Stunde (= nicht mal 2 Impulse pro Sekunde) kommen, die aber eben nur 30ms „breit“ sind.

Grüsse

Uwe

Puffer

sagt alles

MSt

Ich wollte diesen Monstertext ansich allen ersparen. Vor allem mir und meiner Tastatur… Aber wenn du mich (indirekt) so dazu aufforderst… :wink:

Ich glaub dir ja, dass du weisst was ein PC kann. Du kannst bestimmt auch den folgenden Ablauf nachvollziehen. Und dann weisst du die Antwort eigentlich auch schon, warum es eben nicht geht oder mit ziemlichem Aufwand verbunden ist.

Aber was passiert nun in einem PC?
IPS möchte gerne etwas von einer Hardware wissen. Es stellt eine Anfrage an die Windows API. Die API ist aber nur eine Schnittstelle zur 3. Schicht (oder vierte? Ausbildung ist lange her…) des Windows Kernels. Die Anfrage muss also übersetzt werden. Was tun wir also? Wir reservieren uns schnell ein bissel Arbeisspeicher und lassen uns von Windows die dazugehörige Adresse zurückliefern. Damit es nicht zu Zugriffsverletzungen kommt merken wir uns die Länge des Speichers der uns zugeteilt wurde und lassen Windows diesen Speicherbereich durch das Prozessmanagement sperren. Wir haben nun Exclusivrechte auf unsere paar Byte. Jetzt fordern wir Prozesszeit in der Arithmetikeinheit der CPU an die unsere Anfrage ohne zu wissen worum es geht berechnet. Die „Formel“ wie wir das berechnet haben wollen haben wir ihr natürlich gesagt. Auch diese liegt im RAM und auch hierfür mussten wir uns Speicher alloziieren (nein, kein Tippfehler), so nennt man den oben beschriebenen Vorgang. Für das Ergebnis können wir aus ökonomischen Gründen den zuerst angeforderten Speicherplatz verwenden. Das spart Resourcen. Dennoch müssen wir die Länge neu berechnen und merken, denn sonst kommt Müll raus. Um nun selbst zu erfahren was die Antwort war brauchen wir uns nurnoch einen Zugriff auf die die zuerst gemerkte Speicheradresse mit der neuberechneten Länge zu machen. Das Resultat ist nun bereit für den Aufruf der Windows API. Jetzt dürfen wir natürlich nicht vergessen den eben verwendeten Speicher wieder freizugeben. Denn sonst haben wir uns ein sauberes „Speicherleck“ gebaut und der Rechner würde sich nach wenigen Minuten/Stunden/Tagen festfressen.

Das war nur der erste Schritt. Was kommt noch?
Ich will es mal hier abkürzen. Was haben wir bis jetzt erreicht? Wir haben eine Anfrage so formuliert, dass sie dem Windowskernel verständlich ist. Wir könnten sie im 2. Schritt also an den Kernel senden. Windows hat sie bislang noch nicht gespeichert und bearbeitet. Es wurde noch nicht ermitelt welche Adresse die Hardware hat, von der wir etwas wissen wollen. Es wurde noch nicht die Hardwarespezifische Bibliothek ermittelt in der der Algo zur Kommunikation mit der Hardware zu finden ist - Umgangssprachlich der Treiber. Diese muss augelesen werden. Ist sie noch nicht geladen, so benötigt sie eine Adresse und Platz im RAM. Der Algo muss geprüft werden obs überhaupt „Windowscode“ ist. Seit XP wird auch gleich versucht festzustellen obs vielleicht Schadcode ist. Zwischendrin fragt der Virenscannerpolizei was das grad war was da in den Speicher geladen wurde und ob das so seine Richtigkeit hat. Dann wird versucht über die internen Resourcen mit dem ALGO aus dem RAM auf die eigentliche Hardware zuzugreifen. Das heisst in diesem Fall, dass der USB-Bustreiber angesprochen wird, der eine Verbindung zum USB-Chip auf dem mainboard herstellt, die Abfrage rauswirft und die Antwort Puffert bis Windows sie wieder über den USB Treiber abfragt. Diese liefert dann einen binären Wert. Dann wird geschaut von wem die Anfrage kommt und wohin der Wert zurückgeschrieben werden muss.

Jede einzelne dieser Tätigkeiten verlangt unter Umständen mehrere Hundert Einzelschritte (RAM anfordern, Speicheradresse merken, Länge berechnen, Einlesen, Auslesen, Hardwareregister beschreiben und auslesen, Speicher wieder freigeben) denn die CPU versteht ja nur Einsen und Nullen, der Windowskernel aber nicht, IPS nicht und wir auch nicht - das will erstmal formuliert werden. Und auch die einzelnen Schichten des Win-Kernels kommunizieren auf diese Weise miteinander. Und das für die Abfrage eines(!) Ports deines Velleman Boards. Ein Rechner mit 1,4 MHz schafft 42000 rechenoperationen (theoretisch) in 30ms. Bestimmt ein gutes viertel geht dabei für diese interne Verwaltungsarbeit drauf. Allein wenn du die Maus bewegst laufen schon tausende gleichzeitig (quasiparallel) ab. „Nur ein Impuls erfassen“ ist eben doch recht aufwändig und kein „Pipifax“.

Warum kann es das eine Programm und ein anderes nicht?
Es gibt, speziell für solche Vorgänge, Routinen, die einen „eingebauten Turbo“ haben. Es laufen auf einem PC, auch wenn er sich langweilt gut und gerne über hundert (wahrscheinlich weit mehr) Prozesse ab. diese sind in ihrer Priorität unterschiedlich eingestuft. So hat die GUI zum Beispiel eine relativ hohe Priorität, damit du kein Mausruckeln siehst wenn der PC hart arbeitet.

Wenn man die Hauptaufgabe des Programms in einen Thread mit hoher priorität verlagert, so wird dieser schneller abgearbeitet als andere. Die anderen bekommen nach dieser Umverteilung der Rechenzeit nur noch was eben übrig bleibt. Es kann dir also passieren, dass du die Ergebnisse deiner Arbeit zwar vorliegen hast, aber sie nicht darstellen kannst weil durch die hohe Prio der eigentlichen Arbeit keine Zeit mehr zum zeichnen deines Bildschim bleibt. Schon mal versucht nebenbei zu arbeiten während du ein 2GB Zipfile packst. Kannst vergessen…

Warum sieht man das nicht im ProzessManager?
Marketing. Wie würdest du reagieren wenn dein PC beim nichtstun bis zu 25% ausgelastet ist? Ist er aber, sonst müsste man ihn nachts ja nicht ausschalten. Denn wo nichts arbeitet wird kein Strom verbraucht. Haste dich mal gefragt warum der vorgang, der die Uhrzeit in die Taskleiste (genaugenommen die TNA) schreibt oder der, der die Mausbewegung in Coursorbewegung umsetzt nicht aufgeführt ist? Es läuft wesendlich mehr als dort angezeigt wird. Wesendlich…

Ein Buchstabe war früher ein Byte groß. Ein Byte reicht um ein A von einem B zu unterscheiden. Heute hat ein Buchstabe auf dem Bildschirm Informationen zum Font, Style, Größe, Farbe und was weiss ich nicht alles. Ein Boolean (True/False) ist nicht wie man immer meint eine Eins oder eine Null. Es ist eine binäre Zahl mit 32 Stellen. Und rate mal wie groß sie bei einem 64 bittigen Betriebssystem für 64Bit Prozessoer ist. Warum diese Verschwändung von Resourcen? Weil bei jedem Takt so viele Daten durch den RAM und die CPU gejagt werden, dass es keine Rolle mehr spielt. Und weil so viel durchgejagt wird ist eben nicht in jedem 10ms Block unter Umständen grad Platz für einen aufwändigen Hardwarezugriff an extern. Die wird zwar in die Queue gestellt und abgearbeitet, aber eben wenn Zeit ist.

Warum spielt die Programmiersprache in der ein Programm geschrieben worden ist eine Rolle bei der Geschwindigkeit eines Programms?
Bei Programmiersprachen unterscheidet man zwischen Hardwarenahen- und sogenannten Hochsprachen. Egal welche man verwendet, sie muss in maschienensprache übersetzt werden. Diese Sprachen werden unterschiedlich direkt interprätiert. So kann es sein, dass die Maschienensprachenübersetzung eines Hoch-Befehls der Einen nur 5 Maschienenbefehle Umfasst während die der anderen 7 braucht und eine Dritte 12. Wodurch kommt das zustande?

Hast du dich mal gefragt was nötig wäre um unter DOS eine Linie auf deinen Monitor zu zeichen? Es ist ein ziemlicher Aufwand… Und nun schau dir deinen Bildschirm an. Wieviele Linien ergeben zusammen deinen Desktop? Wie verhalten sich die Pixel deines Hintergrundbildes wenn du ein Fenster drüber legst? Ein „Drüberlegen“ gibts aber eigentlich garnicht. Der Computer arbeitet wie ein Zeichentrickfilm. Er zeichnet zig Bilder die Sekunde auf deinen Monitor. Das alles will berechnet werden. Müsste man das heute noch alles selbst machen, so gäbe es auf der Welt vermutlich nur eine Handvoll hochbezahlter Programmierer, die überhaut in der Lage sind das zu programmieren was wir heute als ein Fenster kennen.

Die verschiedenen Programmiersprachen bieten Routinen mit denen man sich darum heute keine Gedanken mehr machen muss. Allerdings lassen sich diese Routinen nicht „mal eben“ in Maschienencode übersetzen. Einfache Routinen lassen sich einfacher übersetzen, komplexere eben nicht. Diese Komplexen Routinen sind so komplex weil sie für den Programmierer einen gewissen Komfort mitbringen. Diese Komfort ermöglicht es einem Programmierer schnell und effizient zu entwickeln. Ein krasses Beispiel: Niemand würde es ernsthaft in betracht ziehen eine grafisch Benutzeroberfläche oder auch nur überhaupt ein größeres Projekt in Assambler (sauschnell) zu schreiben.

IPS ist in Delphi geschrieben. Delphi ist äusserst komfortabel, aber der Maschienencode ist halt immer X Prozent größer und komplizierter als bei Programmen, die zum Beispiel in C++ geschrieben sind. Dadurch ist ein Programm, dass in Delphi geschrieben wurde immer etwas langsamer als das gleiche Programm dass in C++ geschrieben wurde.

Warum wurde IPS nicht in C++ geschrieben?
Diese frage hatten wir vor einiger Zeit schon mal im Forum. Ich weiss es nicht. Wenn du einen Nagel in die Wand schlagen willst um ein Bild aufzuhängen, nimmst du dann den größten Vorschlaghammer für das schnellste Ergebnis oder den mit dem du am besten umgehen kannst, der dir vielleicht für diese Aufgabe auch am geeignetesten erscheint, auch wenn du vielleicht einen zweiten oder dritten Schlag benötigst? Und C++ ist auch nicht die schnellste Programmiersprache. Es gibt wesendlich schnellere. Aber vermutlich wäre IPS dann bis heute nicht mehr als eine Projektstudie in Steiners Schublade.

Und ausserdem: Was glaubst du warum zeitkritische Abläufe immer eine eigene Hardware (als Puffer?) benötigen oder gleich auf ganz anderen Plattformen realisiert werden. Wozu glaubst du müssen deine Daten mit dem Zeitstempel versehen werden. Wenn es in echt so ginge wie es dir deine Software vorgaukelt müsste da nix sortiert werden.

Gruß,

Toni

Habe das Thema leider zu spät gemerkt…

Hier die DLL mit einstellbarer Abfragezeit. Konnte es nicht testen, da das Board in unserem Hardwareturm ist, und ich auch gerade keine Zeit habe alles dafür einzurichten. Es sollte aber gehen. Falls nicht, sag bitte nochmal bescheid.

paresy

IO.vellemanusb.rar (23.5 KB)

Hi Uwe

Hab meinem Auszubildenden (Fachinformatiker, 3. Lehrjahr) als Übung grad die Aufgabe gegeben die tatsächliche Antwortzeit einer Windowsanfrage unter Standardpriorität zu ermitteln. Weil ich finde, dass das Resultat recht brauchbar ist stell ich es hier einfach mal rein. Gemessen wird die reine Antwortzeit ohne Zugriffe auf irgendwelche Hard oder Software. Die Zeit entspricht der mittleren Antwortzeit der vergangenen Sekunde, fast wie ein Ping :wink:

Wenn Max über deine genannten 30 ms steigt (und das wird es ;)) hast du eine gute Chance, dass weiterhin Impulse verloren gehen. Idle sollte um die 15-16ms liegen. Das entspricht 0% Auslastung. Drunter macht Windows standardmäßig dicht.

Toni

WinPing.zip (193 KB)

Hallo Toni,

korrekt, Du hättest Dir den Monstertext sparen können ;-). Die Umstände, die mit einer schnelleren Abfrage notwendig sind, sind völlig unrelevant, da es zahlreiche Beispiele gibt, dass es mit vertretbarem Aufwand und den zur Verfügung stehenden Ressourcen möglich ist. Die erwähnten Messlösungen sind in C++ programmiert und industriemässig nicht billig, aber auch die Velleman-Lösung (zusammen mit der Hardware <50 Euro) zeigt, dass es geht, obwohl die ihr Geld sicher nicht über die Stückzahlen verdienen (wer hat denn schon so ein USB-Experimentierboard ?).

Hallo Steiner,

sagt es nicht. Du hättest meinen Text genauer lesen sollen. Ich kann (z.B. auf einem Prüfstand) stundenlang messen, ohne Datenverluste. Würde der PC dauerhaft nicht in der Lage sein, in 10ms mehrere Botschaften (15-20 sind da völlig normal) auf Platte und Bildschirm zu schaufeln, würde es nach einem Tag Messung vermutlich einige Minuten dauern, bis er den Puffer der Hardware vollends geleert hat. Tut es aber nicht, weil die Hardware gar nicht so viel Puffer hat. Im PC definierte Trigger werden auch zur Prüfstandsüberwachung eingesetzt und leiten z.B. Notabschaltungen ein (da kann man nicht beliebig rumtrödeln). Oder ich greife über den PC in die Fahrzeug-Kommunikation ein, d.h. ein Trigger (z.B. die ansteigende Flanke eines Signals aus dem Fahrzeug) veranlasst den PC, eine Botschaft zu senden, die widerum eine Reaktion im Fahrzeug zur Folge hat. Da kann man praktisch mitmessen, dass der Eingriff ohne Zeitverzögerung stattfindet.

Hallo Paresy,

hoffentlich gibt das keinen Ärger, wenn Du eigentlich unmögliche Sachen programmierst ;-). Ich werde vermutlich erst am Freitag dazu kommen, es auszuprobieren und werde natürlich zurückmelden, ob es klappt. Du bist schon einzigartig.

Grüsse

Uwe

Ich habe nichts von unmöglich gesagt und auch nie behauptet dass keine Zugriffszeiten von unter 100ms möglich sind. Aber für Zugriffszeiten im Nanosekundenbereich (20 in 10ms) ist Delphi nunmal nicht nicht gemacht und so arbeitet es auch nicht. Auf das Warum bin ich, denke ich, ausreichend eingegangen.

Toni

@UweP,

stundenlang messen, ohne Datenverluste / 10ms mehrere Botschaften

man lernt ja nie aus.

MST

PS: diverse hochwertige Meilhaus Messkarten günstig abzugeben