Posts by Andreas

Hallo Kermit29,

"technisch" hast Du vieles richtig gemacht.

Der Kardinalfehler liegt daran, dass Du in der Interrupt-Service-Routine (so man es in Python so nennen darf), VIEL ZU LANGE verweilst UND ZU VIEL rechnest UND dann noch eine zeitintensive formatierte Ausgabe tätigst.

Du hast zwei Flanken. Einmal, wenn der Magnet reinfliegt und das andere Mal, wenn er wieder rausfliegt.

Zwei Interrupts. Zwei Zeiten. Nur, wenn diese beiden Zeiten frisch gesetzt wurden, darf eine Berechnung der Geschwindigkeit - AUSSERHALB der Interrupt-Service-Routine - erfolgen.

Ich bin mir auch nicht sicher, dass es korrekt ist, wenn die erste Zeit den Wert der zweiten Zeit bekommt und auf ein Ereignis für die zweite Zeit gewartet wird.

Wenn das System sooo träge ist, dass die beiden Flanken nicht sauber aufgelöst werden, dann frage eben entweder nur steigende oder nur fallende Flanken ab. Dann weißt Du, wie lange eine Umdrehung dauert. Du kennst den Radumfang = zurückgelegter Weg und kannst darüber die Geschwindigkeit berechnen.

Allgemein sollte in Interrupt-Service-Routinen nur sog. Flags gesetzt werden. Also Zeiten von Ereignissen oder Zustände. In Deinem Fall wird beim "Reinfliegen" die erste Zeit gesetzt. Beim Rausfliegen wird die zweite Zeit gesetzt und ein Flag, dass im Hauptprogramm eine Berechnung und formatierte Ausgabe auslösen soll. So wäre das sauber und klassisch korrekt gelöst.

Beste Grüße

Andreas

Hallo Black_Rider,

willkommen in diesem Forum.

Ein paar Punkte sind mir unklar.

1. Welcher Pegel liegt zwischen TX und GND Deiner Lüftersteuerung an? Sind dies mehr als 3,3 V, dann hast du Deinen Raspberry Pi bereits in die ewigen Jagdgründe bzgl. GPIO geschickt. Die Dich weiterführenden Begriffe wären Pegelwandler oder Spannungsteiler.
2. Wie heißt Deine serielle Schnittstelle nun tatsächlich?
3. Wie hast Du das Device /dev//ttyAMA0 vorbereitet? Angenommen, das wäre das richtige Device. man stty hilft Dir hier weiter. Du musst die tatsächliche serielle Schnittstelle benennen, die Baudrate, die Anzahl der Datenbits und der Stopbits sowie die Parität festlegen. Erst dann ist eine Kommunikation möglich. Bis zu einer störungsfreien Kommunikation sind dann ggf. weitere Einstellungen über stty vorzunehmen (z.B. echoing ausschalten).

Weitere Fragen ergeben sich mit Deiner Rückmeldung.

Beste Grüße

Andreas

Hallo Bern,

ein anderer zielführender Ansatz besteht darin, in der Schleife nicht jedes Mal 0,1 zu addieren, sondern die Schleifendurchläufe zu zählen und dann das Produkt Schleifendurchläufe * 0.1 zu addieren.

Dein Ansatz führt zu einer Fehlerkette, die sich immer weiter vom erwarteten wahren Wert entfernt. Denn die Darstellung von 0.1 und das, was tatsächlich addiert wird, ist entweder immer geringstfügig kleiner oder geringstfügig größer als 0.100000000000000. Bei der Addition des Produktes gleichen sich die Fehler aus.

Besser wird es, wenn Du mit Ganzzahlen arbeitest und erst vor der Addition aud Dezimalzahlen wandelst (wenn dies nicht anders geht).

Bei der Addition einer Ganzzahl zu einer anderen Ganzzahl passieren keine Rundungsfehler (mal unterstellt, dass der Datentyp passend gewählt ist). Und bei der Division durch 10.0 hast Du nur einen einzigen Rundungsfehler. Die Ergebnisse sind mal geringstfügig kleiner oder geringstfügig größer als erwartet - aber nicht immer entweder größer oder kleiner als erwartet.

Was Du aber generell - auch gedanklich - trennen musst: Den Wert einer Variablen für Berechnungen und der Wert zum Anzeigen eines Ergebnisses oder zum Speichern.

Beste Grüße

Andreas

Hallo Bernd,

Quote from Bernd666

Moin jar,

ja, wir alten Säcke....

Zumindest konnte ich damals den kompletten Befehlssatz der 6502 CPU aus dem Kopf.

Waren aber auch nicht viel.

73 de Bernd

Display More

ich kannte sogar noch die sog. "geheinen CPU-Befehle". Mit denen waren Operationen möglich, die in einem Prozessortakt Sachen gemacht haben, für die man sonst mindrstens 3 andere CPU-Befehle hätte nutzen müssen.

Beste Grüße

Andreas

Hallo MCSITK,

da wäre ich skeptisch, dass das, was Du Dir vorstellst sooo einfach umzusetzen wäre.

Du hast einen Stream, der in Text umgewandelt wird.
Sprechpausen, aus denen "Komma", "Semikolon", "Punkt" ermittelt werden könnten, kannst Du nur durch Analyse des (Sound-)Streams erhalten. Wenn das gelänge, müsstest Du aber auch den Stream auswerten, damit Du weißt, an welcher (Text-)Stelle welche Pause zu einem Wortwechsel, Einbau von "Komma", "Semikolon" oder "Punkt" führen soll.

Wenn das mit großem Aufwand gelänge: Wie soll die Pause gestaltet sein bei "Doppelpunk", "Klammer auf", Klammer zu"? Es gibt runde, eckige und geschweifte Klammern... "Ausrufezeichen", "Anführungszeichen", "Fragezeichen"...

Warum willst Du Dir die Arbeit schwerer machen, d.h., mehr bieten als es automatische Übersetzungsprogramme machen / können?

Da ist es vollkommen legitim, an den passenden Stellen einfach zu sagen "Punkt Neue Zeile" oder "Punkt Absatz". Wie bei einem Diktat.

Dann müsstest Du nur noch einen kleinen Parser programmieren, der alle ausgesprochenen Satzzeichen durch die Satzzeichen ersetzt, damit der Übersetzungsteil korrekt gespeist werden kann.

Mach' Dir aber keine große Hoffnung: Die typischen deutschen Schachtelsätze und Nebensätze bekommst Du durch automatische Übersetzung nur ganz selten aufgelöst.

Beste Grüße

Andreas

Hallo RalleB,

Kondenswasser schlägt sich nur auf den Flächen nieder, deren Temperatur <= Taupunkt ist.

Der Taupunkt ist die Temperatur, bei der die Kurve der Dampfsättigung eine relative Luftfeuchtigkeit von 100 %rF aufweist. Siehe auch mal diesen hier.

Ein stromdurchflossener Körper sollte daher niemals der kälteste Punkt sein.

Beste Grüße

Andreas

Hallo Axel,

das Monitor-Programm kannst Du mit jeder Programmiersprache erstellen, die Du dafür nützen möchtest. Zwei meiner Beispiele:

Hier werden 3 Betriebsspannungen, Umgebungstemperatur, CPU-Temperatur, freier, Arbeitsspeicher, freier SD-Speicher und die CPU-Auslastung angezeigt.

Außerdem wird die Ausgabe von dmesg in umgekehrter Reihenfolge ausgegeben.

Ein anderes Beispiel:

Hier wird eine Konfigurationsdatei gelesen, in der zu überwachende Programme und deren Pfade enthalten sind. Die Programme werden gestartet. Bei Bedarf kann man die Programme beenden und neustarten. Programme mit negativer PID laufen gerade nicht. Ist der Button daneben ohne Text, dann kann das Programm auch nicht gestartet werden (falscher Pfad).

Mal als Anregung für Dich.

Beste Grüße

Andreas

Hallo Axel,

da Dein geschilderter Fehler auf Probleme mit der Library bzgl. sm.bus bzgl. I2C hindeutet, würde ich an Deiner Stelle folgendes machen:

• drastisches Erhöhen der Kommunikationsfrequenz (also häufigeres Senden von Kommandos, Auslesen von Ergebnissen).

Wenn das Programm um den entsprechenden Faktor schneller "abstürzt", dann hast Du die Quelle entdeckt. Irgendeine Ressource ist "vollgelaufen".

Wenn das Programm unverändert nach Abgleich der bekannten Zeit abstürzt, dann liegt etwas anderes als Ursache vor.

Loggt Dein Programm irgendwelche Ereignisse mit? Kann es sein, dass die Datei zu groß wird? Wird diese Log-Datei vielleicht im RAM abgelegt?

Hast Du logrotate aktiviert?

Ich würde ein kleines Monitor-Programm schreiben, das allgemeine Zustände ermittelt, wie

• CPU-Temperatur
• Freier RAM
• Freier Speicher der SD-Karte oder des Mediums, von dem Du bootest
• Takt-Frequenz der CPU-(Kerne)
• Verlauf der Load-Averages

und diese und ggf. andere Parameter graphisch auftragen lassen.

Das Monitoring-Programm kann auch gleichzeitig prüfen, ob Deine Anwendung noch läuft - und ggf. neu starten.

Beste Grüße

Andreas

Hallo Franky,

ich will jetzt gar nicht auf jeden Deiner Erklärungsversuche eingehen.

Es hat schon seinen Grund, weshalb das Betriebssystem des Raspberry Pi gelegentlich revidiert wird. Es ist immer problematisch, wenn man irgendwelche "alten" oder "uralten" Vorgehensweisen zu reaktivieren versucht.

Letztlich scheitert es auch an der Unterstützungsmöglichkeit, weil kaum jemand an den alten Zöpfen festhält.

Quote from Franky07

Daher, auch wenn es mich noch einige Zeit kostet, würde ich erst einmal bei dem Ansatz weiter verfolgen wollen, ob sich das Bit-Banging für den I2C auch mit RPi.GPIO umsetzen läßt - Genau dafür bin ich auf der Suche, nach einer alten Routine die man entsprechend anpassen könnte.

Franky

Ich hatte auch zu Wheezy-Zeiten (oder so) mal in der Programmiersprache Icon über Bit-Banging SPI nachgebildet. Einfach, um das mal auszuprobieren.

Ja, es funktioniert.

Was Du aber nicht außer Acht lassen darfst: Du musst jedes Timing, dass Dir das Datenblatt vorgibt, exakt nachbilden. Da stößt Du an Grenzen.

1. Das von Dir eingesetzte Betriebssystem gehört nicht zu den Betriebssystemen, die für die Erfüllung der Eigenschaften für Echtzeit-Betriebssysteme bekannt sind.
2. Python ist ebenfalls weit davon entfernt, echtzeitfähig zu sein. Ein delay(0,92) dauert theoretisch 920 ms. Das kann auch mal 1200 ms dauern - je nach dem, was da noch alles so läuft, und was gerade in dem Moment, in dem der Scheduler Deiner Anwendung wieder Aufmerksamkeit schenken möchte, gerade an wichtigeren Aktionen oder Reaktionen des Betriebssystems mit höherer Priorität eintrudelt.
3. Auf Deinem Raspberry Zero buhlen alle Prozesse (alle des Betriebssystems in der Größenordnung von 60 bis 100), der Python-Interpreter, Deine Python-Anwendung UND alle Deine gestarteten Threads um den einen einzigen Prozessor. Das sorgt für ganz erhebliche Timing-Probleme - wenn Dein Bit-Banging im Bereich ms oder gar µs takten muss.

Ich habe früher mal intensive Untersuchungen durchgeführt, wie reproduzierbar die Laufzeiten (einfachste Zyklen pro Zeiteinheit) sind. Das Ergebnis war genauso bemerkenswert wie schockierend (für RPis mit einem einzigen Prozessorkern).

Bei einem RPi "1" B, RPi A und RPi Zero unterscheiden sich die Maximal- von den Minimalwerten wie 66 zu 100 zu oder 100 zu 150. Also ganz schlecht für Bit-Banging mit engeren Zeittoleranzen, als es diese Verhältniszahlen erlauben.

Auf einem Standard-PC liegen die Verhältnisse schlechtestens bei 97 zu 100 - meistens bei 99,5 zu 100. Damit wäre Bit-Banging auch mit recht engen Toleranzen denkbar.

Gleichzeitig setzt dies dann auch eine Grenze, die auf einem RPi nicht besser möglich sein wird.

Auf einem RPi 3B (+) und RPi 4B sehen diesen Verhältnisse mit recht konstant 97 zu 100 brauchbar gut aus. Es gab aber auch Fälle, da muss wohl einiges Widrige zusammengekommen sein. Da gab es recht heftige Ausreißer - was dann zu erheblichen Störungen im Bit-Banging führen würde und somit zu Fehlinterpretationen von Bits und damit von Daten bzw. Kommandos.

Die Versuche habe ich dann noch mit einem ASUS Tinkerboard und einem NVIDIA Jetson Nano wiederholt. Die Beobachtungen am Tinkerboard entsprechen denen des RPi 3B / 4B. Der Jetson Nano liefert ähnliche Beobachtungen wie der PC.

Zusammenfassung:

Für Dein Vorhaben nutzt Du eine ungeeignete Hardware, ein ungeeignetes Betriebssystem, eine ungeeignete Programmiersprache, ein ungeeignetes Threading auf einem einzigen Prozessor.

Durch den quasi gleichzeitigen Ablauf von Betriebssystem, dessen zahlreichen Tasks und Services, Deiner Programmierumgebung, Deiner Anwendung und Deinen Threads gibt es zu viele Timing-Probleme, die ein Bit-Banging in einer Hochsprache verunmöglichen.

Alternative Lösungsansätze hast Du erhalten. Nutze diese Vorschläge.

Beste Grüße

Andreas

Hallo zusammen,

dann werde ich auch mal...

Bei mir begann das mit der Ausgabe Oktober 2012 der Zeitschrift COM!, die ich Anfang September in den Händen hielt. Ich hatte wohl schon vorher was von Einplatinen-Rechnern gehört - aber nie in Erwägung gezogen, dass ich mich damit beschäftigen sollte.

Ich blätterte so in der Zeitschrift... Den Artikel zum Raspberry Pi las ich intensiv durch. Einmal ... Zweimal ... Dreimal ... Irgendwas war da...

Weihnachten näherte sich und ich hatte keine Idee, was ich meiner Freundin (nee, es gab seither kein Upgrade!) als Geschenkidee nennen könnte. Dann sagte ich mir so, wenn ich bis zu einem bestimmten Stichtag keine bessere oder andere Idee als Raspberry Pi hätte, dann soll es das werden.

Der Stichtag verstrich... Auf dem Geschenketisch befanden sich dann verschiedenste Artikel rund um Raspberry Pi. Am 2. Weihnachtstag habe ich dann mal eine ... ähem ... 2GB SD-Karte fertig gemacht und mit einem ... ähem ... 700 mA-Handyladekabel einen ersten Test gewagt.

Eigentlich wollte ich mit Lazarus/Freepascal ein wenig programmieren. Die Installation funktionierte zwar - aber das Ganze war so langsam, dass da keine Freude aufkommen wollte.

Anmerkung: Auf aktuelleren RPi mit mehr RAM und größerer SD-Karte sieht das völlig anders aus.

Ich erinnerte mich an deutlich weniger Ressource fressende Programmiersprachen... Man kann sich denken, was ich dann installiert hatte. Das war dann gleiche eine andere Qualität.

Mit der Erstellung der ersten Icon-Tutorials kamen dann auch Entwicklungsaufträge aus der Industrie (Medizintechnik, Pharma-Branche). Die Lösungen musste ich dann nach allen Regeln der Kunst validieren.

Mein damaliger Headhunter wollte nicht, dass ich was anderes mache, als den damaligen Kunden (bei dem ich bereits 6 Jahre war) weiter zu betreuen. Ich wollte mit den gefestigten neuen Erfahrungen computergestützte Systeme validieren (CSV). Na ja, es gibt ja nicht nur einen Headhunter. Wenige Telefonate und rund 2 Wochen später war ich plötzlich Mitglied im globalen CSV-Management eines 120.000-Mitarbeiter großen Konzerns und für die CSV-Projekte in Deutschland und Österreich zuständig.

Seit der Zeit habe ich eigentlich in jedem Beratungsprojekt mindestens eine Software entwickelt inkl. der erforderlichen Hardware und Schaltung / Steuerung bereitgestellt.

Da ich alle Rechte am Quellcode behalten möchte, entwickle ich die (lauffähige Grundversion der) Software meistens kostenfrei. Der Auftraggeber trägt dann die Validierungskosten sowie die Anpassung der Software aufgrund der Spezifikationen, die im Rahmen des risikobasierten Ansatzes der Validierung festgelegt werden.

Dieses Konzept hat sich mittlerweile bewährt. Die langfristige Unterstützung regele ich dann durch Wartungsverträge.

Meine Freundin hat mich jahrelang bzgl. Raspberry Pi und Arduino eifrig weiter beschenkt, so dass da mittlerweile eine kleine Sammlung entstanden ist. Außer den RPi2 habe ich jedes RPi-Modell. Bei den Arduinos habe ich auf die Modelle Uno, Mega 2560 und Due beschränkt. Dazu kam dann noch ein ASUS Tinkerboard und ein NVIDIA Jetson Nano. Letzteres toppt nach meinem Gefühl alle RPis um Längen. Das liegt einmal an den technischen Features und am Informationsangebot von NVIDIA.

Beste Grüße

Andreas

Hallo Franky,

da Du an einem I2C-Bus rund 120 Devices (mit unterschiedlicher I2C-Adresse) anschließen kannst, ist es mir nun nicht nachvollziehbar, weshalb Du gleich einen weiteren I2C-Bus benötigst.

WARUM also?

Beste Grüße

Andreas

Hallo Thomas,

da Geany eine IDE ist, kannst Du dort das Programm eintragen, das auf Deinen (Quell-)Text losgelassen werden soll.

Schau mal in das Icon-Tutorial Teil 2. Statt Icon trägst Du dort einfach Deinen Webbrowser ein.

Beste Grüße

Andreas

Hallo zusammen,

ist mir heute bewusst geworden... In diesen Tagen plus/minus wird der Raspberry Pi 10 Jahre alt.

Wer mag, kann ja mal berichten, ob und wenn ja, welche Weichen durch Beschäftigung mit dem Stück Hardware und ggf. Auseinandersetzung mit einem neuen Betriebssystem ander gestellt wurden.

Würde mich mal interessieren.

Sind eigentlich irgendwelche Gedenkfeiern geplant?

Das mit den Forentreffs scheint ja irgendwie eingeschlafen zu sein...

Beste Grüße

Andreas

Hallo oumma,

hier habe ich mal gezeigt, auf welche Arten es möglich ist, Programme zu starten. Eine davon ist über Shebang. Ich kam 2017 auf 15 verschiedene Methoden (Shebang als Nr. 12 aufgeführt).

Beste Grüße

Andreas

Hi Jar,

das gab es doch vor ein paar Jahren schonmal. Testbildgenerator mi'm Raspi drinne.

Ein Link auf Testbilder hätte es wohl auch getan.

Beste Grüße aus Pfreimd und Tännesberg

Andreas

Hallo Wolfgang,

Du hast Deine Entwicklungsaufgabe sehr anschaulich und modular beschrieben.

Mir ist nicht bekant, dass auch nur eine der geschilderten Aufgabe nicht bereits mit einem Raspberry Pi erfolgreich umgesetzt wurde.

Es sollte also möglich sein, dass Du allein durch Zusammensuchen der betreffenden Threads Dein Vorhaben zur Lösung bringst.

Beste Grüße

Andreas

Hallo Martin,

für eine 32 GB-SD-Karte wird ein Dauerbetrieb von 2 Jahren angegeben.

Dein Link enthält keine verwertbaren Aussagen über die Art des Dauerbetriebes. Der Dauerbetrieb als Massenspeicher in einer Kamera ist ein ganz anderer als in einem Rechengerät. Bei einer Kamera werden vergleichsweise wenige - aber recht große - Dateien geschrieben. Löschen passiert auch mal. Überschreiben passiert auch mal.

Bei der Anwendung in einem RPi hast Du viele kleine Dateien, die ständig geöffnet und geschlossen werden. Ständig wird was gelöscht und überschrieben.

Hier ist die Anzahl der Schreibvorgänge der Knackpunkt. Dazu schweigt sich der Hersteller aus.

Meine zweite SD-Karte (16 GB) auf einem RPi B war von Januar 2013 bis 2017 auch im Dauerbetrieb. Auf dem Teil habe ich alle Entwicklungen in der Zeit ausgeführt. Das ist auch ein Vorgang, der recht belastend für eine SD-Karte ist (ständiges Löschen und Überschreiben der gleichen Speicherzellen).

Beste Grüße

Andreas

Hallo raspbastler,

mit Verlaub, wenn sich jemand auf dieses Vorhaben einlassen sollte und versuchen sollte, ohne ein ordentliches Lastenheft zu beginnen, der wird wie ein Fähnchen im Wind immer wieder neue Ansätze starten müssen. Am Ende ist da jede Menge Zeit und Energie investiert, ohne dass das was bei rumkommt.

Und wie gesagt und von framp bestätigt: Solange das Thema "Software-Wartung" nicht annähernd geklärt ist, verbietet es sich, dass sich jemand ernsthaft mit dem Thema auseinandersetzt.

Das Thema "vandalismussicher" ist auch mehrmals gebracht worden.

Letztlich kann jede/r machen, was er/sie möchte und jede/r darf auch jegliche Erfahrungen machen. Aber Warnungen, die definitiv zum Scheitern eines Projektes führen, müssen gemacht werden dürfen.

Beste Grüße

Andreas

Hallo Florian,

wie Du siehst, hast Du zu wenig Informationen bereitgestellt, um jemanden zu begeistern.

Wenn Du wirklich jemand finden möchtest, der das ehrenamtlich macht, dann solltest Du in Vorleistung treten, indem Du ein vernünftiges Lastenheft erstellst.

Ein gutes Lastenheft ist eine gute Voraussetzung dafür, dass auch das Ergebnis = die Software so gut wird, wie Du es im Lastenheft definiert hast.

Das Internet hält gute und auch schlechte Vorlagen für Lastenhefte bereit. Suche Dir eine gute Vorlage aus und werde aktiv.

Wichtig ist, dass Du einen lückenlosen Ablauf(plan) erstellen kannst; denn dann kannst Du Dir sicher sein, dass der ganze Datenfluss sauber durchdacht ist. Das ist nämlich das, was die Kollegen bislang bemängeln. Ohne durchdachten Datenfluss kann niemand eine Software entwickeln.

Das Gesamtergebnis MUSS auch noch vandalismussicher gestaltet sein. Meiner Meinung nach kommt nur die Nutzung in einer Räumlichkeit in Frage, die per se kameraüberwacht ist. Z.B. Eingangsbereich einer Bank, Parkhäuser, ausgewählte Ladengeschäfte in der Innenstadt, ... . Da könnte man ein Terminal stellen, in das man seinen Zielort eingibt.

Aber wie gesagt, dass Konzept muss VOR der Programmierung durchdacht sein und nicht während der Programmierung konzeptionell entwickelt werden.

Was Dir auch klar sein muss, ist die notwendige Software-Wartung. Wer übernimmt diese? Was wird dafür gezahlt? Wenn das auch für umme sein soll, wird sich das niemand ans Bein binden wollen.

Was mit gerade einfällt: Vor knapp 35 Jahren gab es in der Amiga-Szene mal ein bemerkenswertes Projekt. Da hat einer ein Schach-Programm entwickelt. Auf dem Bildschirm erschien ein 8x8-Feld, in dem Buchstaben eine Schachfigur darstellte. Man konnte durch Koordinaten-Eingaben die Figur von Position A auf Position B bewegen. Usw.

Das Programm war extrem spielschwach, langsam, ohne graphische Benutzerführung. Kurzum: Es machte keinen Spaß. Aber die Idee war gut.

Ein Graphiker hat Schachfiguren entworfen. Ein anderer hat eine GUI entworfen. Ein Schachspieler hat eine bessere Routine für die Analyse der Spielsituation entworfen. Ein weiterer Programmierer hat das Programm insgesamt schneller gemacht.

Wenige Wochen später kam ein Schachprogramm mit graphischer Benutzerführung heraus, das recht flott und akzeptabel spielstark war, dass es Durchschnittsspielern durchaus zum Selbsttraining taugte.

Beste Grüße

Andreas

Hallo Hans,

für ein Projekt habe ich mal mehrere Dutzend DS18B20 mit einem Blockkalibrator auf ihre Genauigkeit überprüft.

Ja, die messen alle unterschiedliche Temperaturen, auch wenn sie einer auf 100 mK identischen Umgebung ausgesetzt sind. Ich hatte auch einige Sensoren, die 1,5 K abweichend gemessen haben.

Wenn ich aber jedem Sensor seinen individuellen Offset zugeordnet habe, dann habe ich die Auflösung von 64 mK auch als Messungenauigkeit erhalten. Man kann mit den Teilen also tatsächlich genau und reproduzierbar messen, wenn man vorher einen gewissen Aufwand getrieben hat.

Beste Grüße

Andreas