Einarbeitung in Nextion Displays

[saarfranzose]

die fill-Funktion zeichnet hier ein 5x65px großes rotes Rechteck. Um kein cls zum Löschen des Bildschirms einsetzen zu müssen wird ein zweites Rechteck in Schwarz an die vorherige Position gezeichnet. Das verlangsamt die Ausgabe im Vergleich zu einem bewegten pic

Code:

int i;

void setup() {
    Serial.begin(9600);
    Serial2.begin(9600);

    //zeichne Hintergrundbild
    Serial2.print("pic 0,0,2");
    Serial2.write(0xff);
    Serial2.write(0xff);
    Serial2.write(0xff);
}

void loop() {

        //Bewegung nach rechts
        for (i=101; i<365; i+=1) {
        Serial.println(i);
        Serial2.print("fill ");
        Serial2.print(i);
        Serial2.print(",130,5,65,RED");
        Serial2.write(0xff);
        Serial2.write(0xff);
        Serial2.write(0xff);

        Serial2.print("fill ");
        Serial2.print(i-5);
        Serial2.print(",130,5,65,BLACK");
        Serial2.write(0xff);
        Serial2.write(0xff);
        Serial2.write(0xff);
        }

        //Bewegung nach links
        for (i=365; i>101; i-=1) {
        Serial.println(i);
        Serial2.print("fill ");
        Serial2.print(i);
        Serial2.print(",130,5,65,RED");
        Serial2.write(0xff);
        Serial2.write(0xff);
        Serial2.write(0xff);

        Serial2.print("fill ");
        Serial2.print(i+5);
        Serial2.print(",130,5,65,BLACK");
        Serial2.write(0xff);
        Serial2.write(0xff);
        Serial2.write(0xff);

        }
}

[Reflex-Kalle]

Hi Jupp,

das sieht doch gut aus, was du da machst.

Ich kenne die Nextion nicht, aber wirklich gut geht sowas mit anderen HMI Displays, die einen FTDI EVE Controller der FT800er Serie haben. Die werden über die schnellere SPI Schnittstelle angesteuert, wobei der Bildaufbau z.B. mit tabellengesteuerten Objekten realisiert werden kann. Damit kann man dann z.B. auch eine realistische Wasserfallanzeige für SDRs ohne großen Aufwand erzeugen, ohne dass der ansteuernde Hauptprozessor viele Daten liefern muss. Auch so bieten die FT800er Chips vielfältigste Funktionen, wie Kurvenberechnung aus Punktfolgen usw. Relativ preiswert sind die Displays (in China) auch (z.B. um 30€ für 4,3“...5“ TFT/IPS Displays mit resitiver oder besser noch kapazitiver Touchfunktion). Bekanntester Vertreter sind die Gameduino Displays, die man problemlos mit 4,3“ für 50€ oder 7“ für 80€ aus GB bekommt.

Gruß

(Reflex-)Kalle

[saarfranzose]

Hallo Kalle, ja das könnte man auch mal zu einem Thema machen. In diesem thread soll es aber nur um Nextion gehen.

Eine weitere Funktion wäre für unsere Zwecke brauchbar. Die xpic Funkton blendet einen Ausschnitt eines pic in einem definierten Fenster ein, die X-Koordinate des Ausschnittes liefert wieder eine Zählvariable.



die Syntax:

Code:

for (i=0; i<330; i+=1) {
        Serial.println(i);
        Serial2.print("xpic 160,110,150,150,");
        Serial2.print(i);
        Serial2.print(",0,1");
        Serial2.write(0xff);
        Serial2.write(0xff);
        Serial2.write(0xff);

Ich könnte schon fast zu einem Fazit kommen. Keine Funktion hat die Möglichkeit eine Transparenz in ein Bild zu bekommen. Damit sind die Möglichkeiten einer Skalensimulation auf die gezeigten Beispiele begrenzt (Skalenzeiger im Vordergrund, bewegter Skalenausschnitt in einem Fenster). Für diese beiden Beispiele sind die Ergebnisse allerdings überzeugend und stellen kaum Ansprüche an das verwendete Prozessorboard.

[Reflex-Kalle]

Hallo Jupp,

kann man statt Schwarz neben dem Zeiger nicht auch den jeweils entsprechenden Skalenteil hinzufügen, um den Zeiger scheinbar über oder hinter der Skala zu bewegen? Macht zwar etwas mehr Rechenzeit notwendig, wäre aber wohl die einzige Möglichkeit, wenn ich es richtig verstehe.

Gruß

(Reflex-)Kalle

[saarfranzose]

Kalle, die Idee ist gut! An den entsprechenden Ausschnitt kommt man mit xpic ran. Die überstrichenen Bereiche des Zeigers quasi mit den Ausschnitten des Originalbildes zupflastern.
Den Zeiger optisch hinter einer Skala laufen zu lassen kann ich mir allerdings noch nicht vorstellen.

[Reflex-Kalle]

Hinter der Skala wäre dann irgendwie die Skalabildpunkte mit denen des Zeigers mischen, additiv, multiplikativ oder wie auch immer. Muss man mal experimentieren oder sich mit der Farblehre usw. befassen, wie das theoretisch richtig wäre.

Gruß

(Reflex-)Kalle

[saarfranzose]

die Idee von Kalle hab ich umgesetzt. Das funktioniert sehr sauber und flüssig. Das Moiree im Video kommt vom Abfilmen. Hintergrund und Zeiger sind auf dem Display superscharf. Die Variable sw steht für Schrittweite.

Damit sind schon mal alle Anwendungen für Zeiger über der Skala abgedeckt.



hier mein testcode:

Code:

int i;
int sw=1;

void setup() {
     Serial.begin(9600);
     Serial2.begin(9600);
     }

void loop() {
      for (i=50; i<426; i+=sw) {
      Serial.println(i);
      Serial2.print("fill ");
      Serial2.print(i);
      Serial2.print(",0,5,320,RED");
      Serial2.write(0xff);
      Serial2.write(0xff);
      Serial2.write(0xff);

      Serial2.print("xpic ");
      Serial2.print(i-5);
      Serial2.print(",0,5,320,");
      Serial2.print(i-5);
      Serial2.print(",0,0");
      Serial2.write(0xff);
      Serial2.write(0xff);
      Serial2.write(0xff);
      }

      for (i=425; i>49; i-=sw) {
      Serial.println(i);
      Serial2.print("fill ");
      Serial2.print(i);
      Serial2.print(",0,5,320,RED");
      Serial2.write(0xff);
      Serial2.write(0xff);
      Serial2.write(0xff);

      Serial2.print("xpic ");
      Serial2.print(i+5);
      Serial2.print(",0,5,320,");
      Serial2.print(i+5);
      Serial2.print(",0,0");
      Serial2.write(0xff);
      Serial2.write(0xff);
      Serial2.write(0xff);
      }
}

[Bernhard45]

Das sieht sehr gut aus Jupp. Das können wir so schon als Beispiel-Nextion-Daemon für das iRadio übernehmen. Vielleicht noch Stationsnamen und Titel einblenden! Als nächstes wäre eine Rundskala mit drehenden Zeiger angesagt, ist bei SDL2 mit einer Transformation eines Layers (bzw. gesamten Bildes) schnell gemacht. Für die Transparenz, also Zeiger hinter Glasskala habe ich aber auch noch keine befriedigende Lösung gefunden.

Versuche mal die gesamten Befehle direkt ins Display auszulagern! Also von der Haupt-CPU nur den Umfang der Senderliste und die aktuelle Position in der Senderliste zu übertragen, die for-Schleife muss dann als Skript auf dem Display laufen. Das Display fragt nur 1-2x pro Sekunde bei der Haupt-CPU an welcher aktuelle Sender (Nummer in der Programmliste) eingestellt ist. So wäre das ganze HMI-Konzept dann so wie sich Nextion das vorgestellt hat. Bisher nutzen wir das Display ja eher so wie alle anderen Displays auch, da haben wir noch keine großen Vorteile für die Haupt-CPU erreicht und auch das Erstellen einer Skalensimulation ist im Vergleich zur SDL2-Lösung nicht großartig vereinfacht. Aber kommt Zeit, kommt Rat und dann auch ein Lösungsweg. Ich bleibe an der Sache auch dran.

Gruß
Bernhard

[Reflex-Kalle]

Hi Jupp,

sehr schön gemacht, gefällt mir sehr.

Gruß

(Reflex-)Kalle

[saarfranzose]

..So wäre das ganze HMI-Konzept dann so wie sich Nextion das vorgestellt hat...

da bin ich mir nicht sicher. Das Display ist nach meinen aktuellen Erkenntnissen an den Nextion Editor und dessen Möglichkeiten gebunden.

Im Moment kümmere ich mich um die Zusammenarbeit von Arduino und Nextion. Mein Testcode läuft jetzt auf einem Nano. Ein Filmchen kann ich mir ersparen, die Anzeige ist genauso schnell und flüssig wie mit dem ESP32.
Der Unterschied im Quellcode liegt darin daß der Nano keinen freien seriellen Port hat. Dieser wird dann mit SoftwareSerial emuliert.

Code:

#include <SoftwareSerial.h>

SoftwareSerial mySerial(10,11); // RX, TX
byte NexT[3] = {255,255,255};

int xpos;
int sw=1;

void setup() {
     Serial.begin(9600);
     mySerial.begin(9600);
     }

void loop() {
      for (xpos=50; xpos<426; xpos+=sw) {
      Serial.println(xpos);
      mySerial.print("fill ");
      mySerial.print(xpos);
      mySerial.print(",0,5,320,RED");
      mySerial.write(NexT,3);

      mySerial.print("xpic ");
      mySerial.print(xpos-5);
      mySerial.print(",0,5,320,");
      mySerial.print(xpos-5);
      mySerial.print(",0,0");
      mySerial.write(NexT,3);
      }

      for (xpos=425; xpos>49; xpos-=sw) {
      Serial.println(xpos);
      mySerial.print("fill ");
      mySerial.print(xpos);
      mySerial.print(",0,5,320,RED");
      mySerial.write(NexT,3);

      mySerial.print("xpic ");
      mySerial.print(xpos+5);
      mySerial.print(",0,5,320,");
      mySerial.print(xpos+5);
      mySerial.print(",0,0");
      mySerial.write(NexT,3);
      }
}

[Bernhard45]

..So wäre das ganze HMI-Konzept dann so wie sich Nextion das vorgestellt hat...

da bin ich mir nicht sicher. Das Display ist nach meinen aktuellen Erkenntnissen an den Nextion Editor und dessen Möglichkeiten gebunden.

Das meinte ich doch! Mit dem Editor soll  die GUI gebaut werden und die GUI fordert die Daten vom Hauptprozessor an, der darauf zu antworten hat. Das ist primär der Zweck aller solcher HMI-Display-Systeme inkl. Touch o.ä. Bedienung, nicht das permanent der Hauptprozessor die Zeichenanweisungen, ohne angefragt zu werden, zum Display sendet. Letzteres wäre ja das was wir jetzt mit jedem anderen Display auch machen, bei SmartDisplays kehrt man die Sache um. Das Display fragt gezielt nach den Daten oder gibt Bedienanweisung. Aber das was Du oben schon and Codefunktionalität gezeigt hast, kannst  Du problemlos auf die Displayseite auslagern. Dann wird halt nur angefragt, wieviele Sender und welcher läuft gerade, fertig, ideal für die relativ lahme Schnittstelle. Also zwei numerische Wert im "Nextion"-Protokoll verpackt, fertig. Alles was zeichnet hat nur auf dem Display selbst zu laufen, geht mit dem NExtion-Editior ja einfach.

Gruß
Bernhard

[Reflex-Kalle]

Der eigentlich vorgesehenen Sinn der HMI-Displays ist es wohl, interaktive Touchfunktionen für die steuernden Anwendungen zu vereinfachen. Hoch dynamisch sich verändernde Bilddarstellungen sind bei den Nextion-Displays mit dem die Datenübertragungsgeschwindigkeit beschränkenden RS-232 Interface sicherlich nicht ursprünglich vorgesehen. Mit HMI-Displays auf der Basis der FT800er Chips von FTDI und deren 30MBit SPI Interface sind dann auch hoch dynamische Bilddarstellungen auf einfache Weise realisierbar, ohne dass die Anwendung selbst den kompletten Bildinhalt berechnen und aktualisieren können muss.

Direkt über den Framebuffer angesteuerte Displays und HMI-Displays verfolgen da vollkommen verschiedene Wege, insbesondere auch was die Touchfunktionen zur Interaktion zwischen Display und Anwendung betrifft.

Gruß

(Reflex-)Kalle

[Bernhard45]

Direkt über den Framebuffer angesteuerte Displays und HMI-Displays verfolgen da vollkommen verschiedene Wege, insbesondere auch was die Touchfunktionen zur Interaktion zwischen Display und Anwendung betrifft.

Wobei man natürlich auch bei den Nextions einen Frame- bzw. Bildspeicher auf dem Hauptprozessor realisieren könnte, inklusive aller Grafikfunktionen wie Transparenz. Das ist aber was für Masochisten da man permanent die langsame serielle Schnittstelle im Rücken hat! Das wollte man mit dem Nextion sicher nicht haben. Für die Endversion (auch bei iRadio) der Expermiente, also eine Skalensimulation mit Nextions müsste man wirklich nur den Zeichencode auf Seite des Displays übertragen. Wie das geht hat das weiter oben gezeigte bzw. verlinkte Tutorial schon beschrieben. Ich denke ich werde das Thema für das iRadio nochmal vom Umfang herunterbrechen und zeigen, da hat man dann auch die Parallelen zu besseren (schnelleren) HMI-Systemen bzw. Smartdisplays.

Gruß

[Reflex-Kalle]

Ja Bernhard,

mach mal, vielleicht verstehe ich dann die Funktion der Nextion auch. Kann ja nichtbsvhaden, auch wenn ich bisher kein Nextion in der Hand gehabt habe.

[saarfranzose]

Natürlich liegt die Stärke in der Steuerungstechnik. Dafür sind die Display optimiert, und die parametrierbaren Grundfunktionen wie gauge oder slider oder der Austausch oder das Einblenden von pic's gehen rasend schnell. Einfache events lassen sich ins Display verlagern, die werden einfach den buttons zugeordnet. Aber Schleifen oder if-Abfragen, da hört es dann schon auf.
Für uns ist nur die Frage interessant wie weit kann man die vorhanden Möglichkeiten auf unsere Radioanwendungen zuschneiden. Teilweise ist es ja möglich, und das ist ja schon ein Erfolg. Wenn ich ein 2,4" Nextion für noch keine 14 Euro einkaufen kann und das einfachste CPU-Board kann es mit einfachen seriellen Anweisungen animieren dann hab ich gegenüber anderen Displays, denen man jedes Pixel einzeln senden muss, einen echten Vorteil. Ich werde bald eine Radioanwendung vorstellen.

[saarfranzose]

Hier jetzt meine erste Integration des Nextion-Display in mein Arduino-Nano-Radio. Sie zeigt daß meine Suchlauffunktion sehr langsam ist. Das liegt daran daß alle 100kHz der neue Frequenzwert per I2C in den Radiobaustein geschrieben wird, dann der RSSI-Wert zurückgegeben und ausgewertet wird. Das kostet nun mal Zeit, und das Display wird richtig ausgebremst. Von animierten Skalen kennt man das normal nur umgekehrt.



Es ist darauf zu achten daß die Texte ausserhalb des Skalenzeigerbereiches plaziert werden, weil sonst die Hintergrundrestauration bei der Zeigerbewegung die Texte immer wieder löscht.

Die X-Position des Zeigers wird mit einer map-Funktion errechnet, in die auch der rechte und linke Rand eingerechnet ist. Die gerundeten Werte könnten die Ursache sein daß der Zeiger etwas unruhig ist.

xpos=map(seekall,875,1080,80,380);

was wäre noch von Interesse zu zeigen? Vielleicht meine komplette subroutine zur Skalenzeigerbewegung?

Code:

void NXChannel()
{
 //Zeichne Zeiger
 xpos=map(seekall,875,1080,80,380);
 mySerial.print("fill ");
 mySerial.print(xpos);
 mySerial.print(",30,5,250,RED");
 mySerial.write(NexT,3);
 
 //Lösche Bereich links vom Zeiger
 mySerial.print("xpic 80,30,");
 mySerial.print(xpos-80);
 mySerial.print(",250,80,30,0");
 mySerial.write(NexT,3);
 
 //Lösche Bereich rechts vom Zeiger
 mySerial.print("xpic ");
 mySerial.print(xpos+5);
 mySerial.print(",30,");
 mySerial.print(385-xpos);
 mySerial.print(",250,");
 mySerial.print(xpos+5);
 mySerial.print(",30,0");
 mySerial.write(NexT,3);
 
}

[Bernhard45]

 Einfache events lassen sich ins Display verlagern, die werden einfach den buttons zugeordnet. Aber Schleifen oder if-Abfragen, da hört es dann schon auf.

Diese Kontrollstrukturen lassen sich in dem Eventcode doch problemlos auf der Displayseite benutzen Jupp! Wenn Sie nicht vorhanden wären, könnte man Sie auch einfach mit den Timern/Variablen-Bausteinen (ähnlich der in Delphi oder .Net/C#) nachbilden!

https://www.itead.cc/blog/advanced-appli...-animation

Damit lässt sich die Kommunikation zwischen Frontprozessor u. Hauptprozessor auf wenige numerische Werte runterschrumpfen und die muss die Haupt-CPU auch nur dann senden, wenn das Display diese anfordert, also so wie Nextion das als "the Nextion-Way" darstellt (und fast schon als eigene Idee - was Sie nicht ist - vermarktet).


Gruß
Bernhard

[saarfranzose]

so ganz verstehe ich es nicht, Bernhard. Die Kommunikation ist doch schon auf einem Minimum. Grundsätzlich. Die paar seriellen Anweisungen belasten unsere CPU nur unmerklich.

Heute dann gleich zwei Tiefschläge. Dein link von obendrüber brachte mich auf die Idee mit Einzelbildern zu arbeiten. Für eine Auflösung in 100kHz-Schritten wären für ein UKW-Radio 205 Bilder notwendig. Ein Bild mit 480x320px hat eine Dateigröße von ca. 40kb. Aber dekomprimiert im Nextion Speicher belegt es knapp 300kb. Damit ist der Speicher mit 10 Bildern schon an seiner Grenze. Schade .. auf die Art hätte Transparenz keine Rolle mehr gespielt, weil der Zeiger im Bildbearbeitungsprogramm statisch reingebaut würde.

Als nächstes wollte ich eine Halbkreisskala bauen mit der Gauge-Funkion. Auch hier Fehlanzeige, weil alle Komponente komplett innerhalb der Displayfläche liegen müssen. Bei iRadio ist das kein Problem, siehe mein Millivoltmeter.


  columbus-error.jpg (Größe: 63,38 KB / Downloads: 99)

Jetzt gehen mir langsam die Ideen aus.

[Bernhard45]

so ganz verstehe ich es nicht, Bernhard. Die Kommunikation ist doch schon auf einem Minimum. Grundsätzlich. Die paar seriellen Anweisungen belasten unsere CPU nur unmerklich.

Hallo Jupp, 

mit deinem Code bist Du jetzt auf dem Stand unserer Standard-Displaydaemonen im iRadio. Also displayd von den eInks, Oleds und TFTs ohne X11-Ansteuerung. Dort werden ja auch nur Zeichenanweisungen pro verändertem Bild gesendet, mal über I2C, mal über SPI oder hier über serielle Schnittstelle (RX/TX). Das ist aber eigentlich nicht das Ziel was wir mit dem Nextion erreichen wollen oder können, denn wir reduzieren den Kommunikationsaufwand für das "Hauptsystem" nicht. Der ESP32 schafft die Kommandos, klar. Aber ein ESP32 würde auch die anderen nicht Nextion-Displays so flüssig ansteuern können!


Mit solchen Smart-Displays, also auch dem Nextion, sollte die Kommunikation so aussehen.


Internetradio gibt einen Sender wieder: - gar keine Kommunikation

Sender wird umgeschaltet, zum Beispiel durch Touch-Bedienung.

Kommunikation Display zur Haupt-CPU: P+ oder P-

Haupt-CPU schaltet neuen Sender ein.

Kommunikation Haupt-CPU zum Display: Ok.

Kommunikation Display zur Haupt-CPU: Programmnummer?

Kommunikation Haupt-CPU zum Display: numerischer Wert

Display errechnet mit diesem numerischen Wert die neue Skalenzeigerposition und rendert alle Bilder (deine Codeschleife oben) bis der Zeiger seine Zielposition eingenommen hat! Deine Zeichenbefehle von oben laufen also auf dem Displayprozessor, nicht auf der Haupt-CPU und es werden da auch keine Zeichenbefehle über die serielle Schnittstelle gesendet. 

Damit sind also nur ein paar Byte an Datenübertragung nötig um ein flüssig laufendes HMI zu erhalten, auch wenn die Haupt-CPU nur eine "Krücke" ist. So könnte also auch problemlos ein Arduino oder Pic18F ein Internetradio bewältigen. Die Daten reichen diese kleinen Prozessoren dann von einem zusätzlichen Ethernetport ENC28J60, ... oder WiFi-Shield an einen VS1053 o.ä. weiter. Damit sind Sie gut ausgelastet, brauchen sich aber rein gar nicht um das HMI oder gar die Zeichenbefehle für eine Skalensimulation kümmern, denn das ist rein die Aufgabe dieser Smart-Displays mit eigener CPU wie dem Nextion.  Dafür sind die Displays eigentlich gedacht und prima geeignet! The Nextion-Way! 

Hat der Hauptprozessor nämlich genug Rechenleistung, können Touchaufgaben und HMI mittels GUI-Editor von QT, fltk etc. genauso einfach gelöst und gebaut werden, wie mit dem Nextion. Da haben die Smart-Displays gegenüber "dummen" Displays mit X11, Framebuffer etc. keinerlei Vorteil, da die Grafikbibliotheken wie QT die Komplexität sowieso prima vom Entwickler entfernt halten, dafür braucht man halt kein Nextionl nichtmal für die Touchfunktionalität. Diese Smart-Displays sind erst dann wichtig wenn man die beiden Aufgaben komplett auf zwei Systeme auslagern will, also HMI auf das eine, Rest aufs Andere. Entscheidet man sich für diesen Weg, dann hat das "Andere" aber auch rein gar nichts mehr mit dem Zeichnen der Nutzerschnittstelle zu tun! Ansonsten kann man sich den Aufwand sparen, weil es keine Vorteile bringt. Den GUI-Editor gibt es für beide Systemvarianten, ist also nicht das Entscheidungsmerkmal für oder gegen eine Variante.

Also strikt HMI von Nano-Aufgaben trennen, dann kann auch die Anzeige aus deinem Video hier 




flüssig laufen so wie weiter oben gezeigt. Der Nano stimmt ab und das Display arbeitet die "Zeichenbefehle" auf dem eigenen internen Prozessor gab. Beide CPUs kommen sich nicht ins Gehege und sprechen nach obigen Beispiel nur relativ selten (zu Synchronisationszwecken) miteinander. Also keine Zeichenbefehle in einer Schleife von Haupt-CPU über die serielle Schnittstelle zum Display übertragen! Der Nano muss die Zeigerbewegung gar nicht "treiben" (das macht das Display selbst) und die eingesparte Rechenzeit auf dem Nano steht anderen Aufgaben zur Verfügung. Ich hoffe Du verstehst wie ich das meine?

Sowas hier, nur mit Nextion-Display und schneller, flüssiger Skalensimulation nach deinem Vorbild wäre also auch mit einem ATmega/Arduino machbar. Dazu darf der kleine uC aber nur aktuelle Programmnummer/Anzahl Programme in Senderliste auf Anfrage zum Display übertragen. Bloß nicht auf die Idee kommen die Zeichenbefehle über die serielle Schnittstelle schicken, so wie Du das in deinen Codebeispielen oben machst. Die Zeichen-"Algorithmen" für die Skalensimulation müssen also schon im Nextion sein.



Gruß
Bernhard

[Bernhard45]

Für eine Auflösung in 100kHz-Schritten wären für ein UKW-Radio 205 Bilder notwendig. Ein Bild mit 480x320px hat eine Dateigröße von ca. 40kb. Aber dekomprimiert im Nextion Speicher belegt es knapp 300kb. Damit ist der Speicher mit 10 Bildern schon an seiner Grenze. Schade .. auf die Art hätte Transparenz keine Rolle mehr gespielt, weil der Zeiger im Bildbearbeitungsprogramm statisch reingebaut würde.

Siehe Idee von weiter oben! Es müsste ja nur ein(!) leeres (ohne Zeiger) Gesamtbild und dann x-Minibilder des Zeigers hinter dem Glas im Speicher gehalten werden, um den Transparenzeffekt zu erzielen. Dann kannst Du das passende Zeiger-Minibild über das Gesamtbild an der richtigen Stelle zur Anzeige bringen und es sieht so aus als wäre der Zeiger hinter der Skale. Aber die Erstellung dieser Minibilder kannst zu keinem antun, dass sind je nach Bildschirmbreite hunderte Minibilder!