Beiträge von schlizbäda

    und warum funktioniert es dann nicht bei mir? Ich habe den neusten Raspberry Pi

    Ob etwas unter Raspbian funktioniert oder nicht, hat ganz wenig bis gar nichts damit zu tun, welches RPi-Modell man verwendet (bis auf einige Ausnahmen bezüglich der GPIO-Belegung bei den ganz ersten Modellen von 2012 oder 2013). Die Foundation achtet bis heute darauf, dass es jeweils ein Image für Raspbian Desktop bzw. Raspbian Lite gibt, das auf allen RPis läuft. Für diese meines Erachtens nicht hoch genug zu bewertende Kompatibilität "opfert" die Foundation sogar die 64bit-Fähigkeit des BCM2837 des RPi3, da sie nur das eine 32bit-Image veröffentlicht.

    Bei Dir funktioniert es wohl in erster Linie wegen der Geschichte mit dem User pi nicht. Auch rpi-update ist ein ganz "böser" Befehl! Aber da plappere ich jetzt nur das Gesagte meiner Vorredner nach, denen ich unumwunden recht gebe.

    Flashe doch einfach das Raspbian neu auf die SD-Karte und fange nochmals von vorne an. So arg viel wirst Du ja damit noch nicht gemacht/installiert haben...

    Wenn doch, nimm dies als Anlass, frühzeitig und häufig Backups auf der PC-Festplatte zu machen. Ferner schadet es nicht, neben "der einen" SD vom RPi (auf der sich womöglich auch noch NOOBS befindet) noch ein paar weitere mit 8-16GB vorrätig zu haben, einfach um "schnell" etwas ausprobieren zu können.

    Ist nicht böse gemeint, sondern resultiert teilweise einfach aus eigener Erfahrung.

    Hallo nurazur,

    Mein Problem ist, dass es offenbar keinen einfachen GPIO-Treiber für Windows gibt, über den man direkt Bytes über die GPIB-Schnittstelle schicken kann.

    Ich sehe es auch so, dass der Selbstbau problematisch ist, weil man irgendetwas übersieht, auch wenn die Technik an sich einfach wäre. Beim https://www.mikrocontroller.net/articles/GPIB-RS232-Schnittstelle schreibt es der Verfasser ja selbst, dass er es nicht zu 100% vollständig/richtig umgesetzt hat.

    Bei der Bachelorarbeit aus dem Titel fehlt jegliche Erfahrung. Die universitäre Umsetzung dürfte zwar einigermaßen vernünftig erfolgt sein, aber auch da kennt man nicht alle möglichen Konstellationen. Außerdem hätte deren Verwendung zur Folge, entweder eine zusätzliche Prüfsoftware für den RPi zu schreiben oder eben auf dem RPi eine LAN- bzw. RS232-Anbindung zu erstellen, damit er mit einem Windows-PC kommunizieren kann.

    Es ist richtig, dass man die Kosten für gute und stabile Hard- und Software im industriellen Umfeld nicht scheuen darf. Bei unserer Software wäre es dann aber kundenabhängig, von welchem Hersteller das Equipment kommt. Und ich habe auch gelesen, dass sich die (Treiber-)Software der beiden Platzhirsche NI und Keysight auf dem gleichen PC gerne in die Quere kommt, was Du ja auch bestätigst.

    Hilfreich ist für mich Deine Aussage, dass die Prologix-Module anscheinend recht gut funktionieren. Wenn man sich low-level auf das Senden/Empfangen von SCPI-Kommandos herablässt, sollte auch die Kommunikation mit den Geräten von Keysight oder National Instruments funktionieren. Ich habe so etwas schon mal auf der RS232-Schnittstelle für das Keysight 34970A und das E3634A relativ problemlos umgesetzt. Wenn die Prologix-Teile die GPIB-Handshakeleitungen richtig bedienen, sollte das damit auch über die GPIB-Schnittstelle möglich sein.

    GPIB über den Linux-Treiber(?) Linux-GPIB ist interessant, ebenso eine (vermutlich extrem aufwendige) Einbindung des VISA-Standards in unsere Software oder die Umsetzung von VISA für Linux. Du sagst es, wohl nicht unmöglich. Das größte Problem ist hier die Zeit!

    am Commodore war das der Befehl open der die Bits an der Schnitte setzt ATN oder so, ein Multimeter einstellen war R1 aber welcher Messberei mit R1 ist kann man nur in der Anleitung vom DMM nachlesen, alle habe ich auch nicht mehr.

    Das Handbuch zum PET2001 hat das primer erklärt, aber das finde ich nirgens mehr.

    Ja, das waren noch Zeiten! Meine späte Kindheit/frühe Jugend prägte der C64, dessen User-Port eigentlich auch eine Schnittstelle nach IEEE488 war (Quelle).

    Also diese Befürchtung hatte ich auch und Dein Beitrag bestätigt mich diesbezüglich leider.

    Wenn ich jetzt keinen vernünftigen GPIB-Treiber für Windows finde, werde ich mich wohl wirklich für die RPi-Geschichte entscheiden (müssen). Für Linux gäbe es ja solche Treiber bereits: Linux-GPIB.

    Aber (nicht nur unsere) Industriekunden schwören selbst heutzutage immer noch auf Windows. Daher wurde auch unsere Software für dieses Betriebssystem erstellt.

    EDIT:

    ich fand gerade das: Prologix GPIB-USB-Controller auf Basis eines virtuellen COM-Ports

    WaldiBVB:

    Eigentlich geht es darum, eine .NET-Software unserer Firma, ein Testsequenzer zum PC-basierten Prüfen von Flachbaugruppen und Fertiggeräten, für die Kommunikation über eine GPIB-Schnittstelle nach IEEE488 bzw. IEC-625 zu ertüchtigen. Eigentlich ist das GPIB-Protokoll an sich relativ einfach und hat dann wohl die Entwicklung der für lange Zeit am PC verfügbaren Parallelschnittstelle ("Centronics-Schnittstelle") für den Druckeranschluss beeinflusst. Das Problem ist hier speziell unter Windows, dass es im Gegensatz zur seriellen UART-Kommunikation (RS232, auch RS422 oder RS485) schwierig ist, (allgemeingültige) Treiber zu finden, die man relativ leicht in eigene Software einbinden kann, um eine einfache Kommunikation zu den Messgeräten über SCPI-Kommandos aufzubauen.

    Prinzipiell steht einer industriellen Anwendung des RPi nichts im Wege, wenn man einige Randbedingungen beachtet:

    - saubere, störungsfreie Spannungsversorgung

    - Raspbian (oder anderes RPi-Betriebssystem) über einen Read-Only-Mount aufziehen, um diese (unsägliche) Power-Down-Sache in den Griff zu bekommen

    - stabile, gut getestete Produktivsoftware (egal ob Fremd- oder Eigenkreation)

    Die Verwendung von Linux/RPi wäre eine Option, wenn meine Suche nach einem vernünftigen Windows-Treiber ergebnislos bleiben sollte

    jar:

    Den Link https://www.mikrocontroller.net/articles/GPIB-RS232-Schnittstelle fand ich auch bereits. Es ist ein ganz interessanter RS232-GPIB-Umsetzer, aber offenbar beim gleichzeitigen Betrieb mehrerer GPIB-Geräte nicht 100% sauber umgesetzt (Handshake). In einer Industrieanwendung muss sowas einfach unter allen Umständen sauber und stabil laufen.

    Das Ganze sehe ich nicht als "entweder - oder". Eine derartige RPi-Lösung würde als Zwischenstück implementiert werden. Da unsere Software unter Windows läuft, wäre es schöner, ohne Hardware eine programmtechnische Schnittstelle zu GPIB zu schaffen, wie sie für RS232 existiert. Dabei käme besipielsweise ein Keysight 82357B zum Einsatz. Die dafür nötige Software Keysight IO Libraries Suite, die auch Treiber dafür enthält, ist halt relativ proprietär inklusive dem ganzen Gedöns rund um die IVI-Foundation wie des Konzept der VISA-Library und lizenztechnisch nicht unproblematisch, siehe die jeweiligen EULAs...

    Der zweitschönste Weg ist eben, eine RS232-GPIB-Schnittstelle wie auf http://www.mikrocontroller.net zu verwenden oder einen RPi, der die GPIB-Schnittstelle auf Basis dieser Bachelorarbeit implementiert und eine Kommunikation zum Haupt-PC über RS232 oder LAN ermöglicht. Oder alternativ einen käuflichen Konverter von einem "namhaften" Hersteller wie National Instruments oder Keysight (z.B. Keysight E5810B)

    schlizbäda

    Servus,

    Im Rahmen einer ähnlichen Aufgabe in der Arbeit (allerdings unter Windows 7) bin ich jetzt rein aus Interesse am Thema beim privaten Surfen auf diese Bachelorarbeit an der Universität Wien gestoßen:

    Messgeräteansteuerung unter Python

    Hier geht es um die Ansteuerung von älteren(?) Messgeräten, die mit einer GPIB-Schnittstelle ausgestattet sind. Der Student hat in seiner Arbeit diese Schnittstelle mit den GPIOs eines RPi umgesetzt. Fand ich jetzt ganz interessant und wollte es Euch nicht vorenthalten. Vielleicht kann es der eine oder andere "Hardwerker" (kein Tippfehler) in diesem Forum gebrauchen?

    Eigentlich suchte ich einen GPIB-Treiber für Windows, aber mittlerweile stößt man bei sowas schneller auf eine Lösung mit einem RPi :lol:

    Wobei es morgen eine Überlegung wert sein wird, da wird sich der Chef wieder mal richtig freuen;)

    schlizbäda

    Hähä,

    ich habe zum Test nochmals das aktuelle Raspbian Stretch with Desktop geflasht und die apt-Gaudi nochmals getestet. Mit dem Image vom 13.03.2018 ist es tatsächlich so, dass man zunächst folgende Befehle in dieser Reihenfolge absetzen muss:

    Code
    sudo apt update   # egal ob apt oder apt-get
    sudo apt upgrade
    uname -a          # liefert: Linux raspiblaster 4.14.30-v7+ #1102 SMP Mon Mar 26 16:45:49 BST 2018 armv7l GNU/Linux
    sudo apt update   # hier das Update der Paket-Metadaten NOCHMALS aufrufen!

    Meine Vermutung ist, dass nach dem Flashen des Images zunächst die Metadaten dem Stand vom 13.03.2018 entsprechen. Dann führt man mit diesen aktualisierten Metadaten den Upgrade durch und erhält einen Distributionsstand vom 26.03.2018 und bei dem ist es offenbar erneut erforderlich, die Paket-Metadaten zu aktualisieren. Ein weiteres sudo apt upgrade oder auch sudo apt dist-upgrade liefert die Meldung, dass alle installierten Pakete aktuell sind.

    Aber das ist jetzt eine reine Vermutung eines echten Linux-Noobs.

    apt ist cooler als apt-get, denn die Ausgabe ist farbig und es wird ein geschmeidiger Fortschrittsbalken angezeigt :cool:

    apt-get vs. apt

    Dieses Projekt bleibt sich treu und liefert ein neues Schmankerl für den Linux-Dauernoob:

    Kennt jemand den Unterschied zwischen apt-get und (dem neueren) apt? Oder was hat es damit schon wieder auf sich?

    Bei Durchführung meines Tutorials aus Kapitel 3 in meiner Doku unter dem aktuellen Stretch vom 13.03.2018 schlägt nach Ausführung von

    sudo apt-get update

    sudo apt-get upgrade

    das Kommando

    sudo apt-get install eject

    und auch etliche andere sudo apt-get install ... fehl.

    Erst ein

    sudo apt update 

    führt dazu, dass die Pakete bei Aufruf von

    sudo apt install ...

    wirklich installiert werden!

    Spoiler: Beispiel mit Fehlermeldung

    sudo apt install eject

    Code
    Reading package lists... Done
    Building dependency tree
    Reading state information... Done
    Package eject is not available, but is referred to by another package.
    This may mean that the package is missing, has been obsoleted, or
    is only available from another source
    
    E: Package 'eject' has no installation candidate

    Nach erneutem sudo apt update liefert sudo apt install eject dann

    Ist aber nicht spezifisch für das Paket eject

    Ach, dann werde ich Kapitel 3 nochmals umschreiben müssen! Gut, dass ich die Doku noch nicht auf englisch übersetzt habe, Faulheit zahlt sich eben immer wieder aus!

    schlizbäda

    Sorry für die (vielleicht blöde) Idee, die Dir dann doch sooo viele Sorgen bereitet hat! :denker:

    Nein, das war überhaupt keine blöde Idee. So eine halbseidene Funktionsweise ohne Korrekturmaßnahmen hätte mich richtig gestört. Erst jetzt ist das Ganze nämlich einigermaßen so, wie ich es mir anfangs vorgestellt habe.

    Weiterhin offen ist die Sache mit der S-USV pi advanced mobile (siehe Beitrag #1)

    Es wäre schön gewesen, damit einen Batteriebetrieb samt sauberem/kindgerechtem Herunterfahren beim Ausschalten zu realisieren. Aber ich glaube, ich habe die mobile-Variante der S-USV zu früh bestellt, da enthielt deren proprietäre Soft-/Firmware wohl noch einige Fehler...

    Das Beste ist aber folgendes:

    Neben der Tatsache, dass die eject-Taste des verwendeten Laufwerks LG GP50NW40 Probleme bereitete, ist es auch in der Einlesephase der CD relativ langsam. Dieses Geschwindigkeitsproblem führte ich zunächst auf den verwendeten RPi3B (ohne Plus) zurück. Letztens war ich mit dem kleineren Buben (5 Jahre) wegen eines neuen Ethernet-Switches in der Stadt in den einschlägigen Elektronikgroßmärkten. Als wir in der PC-Abteilung bei den CD-ROM-Laufwerken vorbeikamen, sagte er, er wolle auch so einen CD-Spieler wie sein größerer Bruder. Dann nahm ich ein CD-ROM-Laufwerk für ein Desktop-/Tower-PC-Gehäuse (eigentlich ein Blu-ray Disc Rewriter LG BH16NS55) zum Preis von 25,00€ mit, u.a. weil dessen eject-Taste nicht am beweglichen Teil verbaut ist.

    Außerdem erwarb ich gleich einen (wohl überteuerten) USB2.0-S-ATA-Wandler (Vivanco 31952) für über 30,00€.

    Zu Hause schloss ich dieses Gespiel zum Test an einem herumliegenden RPi1 an, auf dem auch meine audacious-Software läuft (gleiches SD-Image wie am Raspiblaster), um die Screenshots für meine Doku zu erstellen.

    Resultat:

    Das Einlesen der CD an diesem Gerät geht (trotz RPi1?) gefühlt dreimal so schnell, jedenfalls mehr als schnell genug. Beim Betätigen der eject-Taste kommt die gleiche harmlose Fehlermeldung von audacious wie am (richtigen) PC ohne Hängen. Das eject-Problem ist wohl eine Treibergeschichte des ursprünglichen Laufwerks, wie ich bereits in Beitrag #2, Unterpunkt 1 offenbar leider richtig vermutet habe. Frei nach Loddar Matthäus: "Again what learned"

    schlizbäda

    Yeah!

    Endlich habe ich den Durchbruch geschafft und der Raspiblaster ist einigermaßen so, wie ich mir das vorstelle. Zumindest reicht es, den Erledigt-Haken zu setzen. Ich verwende jetzt doch audacious in der aktuellen stable-Release 3.9 vom 19.08.2017 mit Ergänzung der eject-Funktion einschließlich der notwendigen eject-Sperre über GPIO4 (wiringPi: shell-Kommando gpio). Hier ein Screenshot vom RPi-Desktop mit der von mir angepassten audacious-Variante:

    Der von mir angepassten Quellcode von audacious befindet sich im github-Repository .../schlizbaeda/audacious-raspiblaster zum Download. Außerdem habe ich mit LaTeX eine pdf-Bedienungsanleitung/Dokumentation für den Raspiblaster verfasst, in der u.a. in Kapitel 3 beschrieben ist, wie der angepasste audacious-Quellcode auf dem RPi zu kompilieren ist. Die Bedienungsanleitung befindet sich im github-Repository .../schlizbaeda/raspiblaster-manual. Derzeit liegt nur eine deutschsprachige Version vor, ich will sie aber auch noch auf englisch übersetzen - versprochen! git gibt ja eine derartige Variantenvielfalt in einem Repository mittels mehrerer Branches her :) EDIT 22.05.2018: Die Dokumentation liegt mittlerweile in englischer und deutscher Sprache vor.

    Wer Bock hat, kann sich ja mal die Doku anschauen. Und dann mit Kritik und Verbesserungsvorschlägen nicht hinter dem Berg halten. Immer her damit!

    PS:

    Übrigens ist das Beitrag #42 in diesem Thread. Die Antwort auf alle Fragen! ;)

    schlizbäda

    Übrigens wird das Repo tatsächlich gerade aktualisiert. Mir ist das was dem TE passiert ist auch mit mehreren Paketen aufgefallen. Jetzt scheints aber wieder zu laufen!

    Das kann ich bestätigen. Letztens lief bei mir ein

    sudo apt-get install eject

    auf einem jungfräulichen Raspbian nicht.

    Mir gingen kurzzeitig die gleichen Gedanken durch den Kopf wie dem TE, besann mich dann aber eines Besseren. Offenbar wurde der Linux-Kernel von 4.9.x auf 4.14.30 (oder so) hochgezogen. Da kann es vermutlich schon mal an großen "Kleinigkeiten" haken :)

    Linus hat die Problematik aber recht schön beschrieben und versucht, dem TE die Angst zu nehmen. Wenn das dann Dritte nicht verstehen (der TE schon), dann :no_sad:

    Dem ganzen Forum rate ich mal, nicht jedes Wort auf die Goldwaage zu legen. Ironie ist im geschriebenen Wort oft schwieriger zu erkennen, da der Tonfall in der Stimme fehlt. Smileys sind nicht immer ein adäquater Ersatz. Bei Kritik -- egal welcher Art -- sollte man sich erst mal an der eigenen Nase fassen, cool bleiben und berechtigte Kritik auch annehmen...

    jm2ct schlizbäda

    Mei dass då nix oafach is!

    Derzeit manipuliere ich den C++-Code von audacious so, dass die neue Funktion "eject" als Toolbar-Button und als Menüpunkt (Wiedergabe-->Eject) zur Verfügung steht (erfolgreich ergänzt)

    und

    die in den Beiträgen #11 und #25 umgebaute Auswurftaste des CDROM-Laufwerks über GPIO4 gesperrt wird. Dies ist beinahe erfolgreich umgesetzt: Die Sperre an sich funktioniert.

    Aber jetzt erstmal wieder ein bissl mimimi: :mad_GREEN:

    Neben der Tatsache, dass mich die nicht nur bei mir, sondern selbst bei Experten gefürchtete C-/C++-typische #include/Makefile-Geschichte immer wieder ausbremst, habe ich es jetzt tatsächlich geschafft, das audacious-Projekt auf dem RPi zu kompilieren und dabei die pigpio-Bibliothek -lpigpiod_if2 über die Datei buildsys.mk in das Projekt mit einzubinden. Das ist die Version von pigpio, die den GPIO-Zugriff über den pigpio-Daemon durchführt. Damit braucht das Clientprogramm (audacious) keine Rootrechte.

    Aber was passiert jetzt als neues Schmankerl?

    Nach Absetzen von sudo pigpiod läuft die Audioausgabe gar nicht oder nur mit ca. 50% der Originalgeschwindigkeit. :baeh2:

    Ein geschmeidiger sudo killall pigpiod führt sofort dazu, dass nach dem Kill die Audiogeschwindigkeit beim laufenden Musikstück (Nightwish: "Dead Gardens") sofort wieder auf 100% ansteigt.

    Ich vermute, dass pigpio den I²S-Bus irgendwie ausbremst... --> siehe hier

    Bisher kenne ich mich mit den GPIOs überhaupt nicht gescheit aus, aber folgende Lösungsvorschläge geistern in meinem Kopf herum:

    - Die "normale" pigpio-Variante -lpigpio ohne Daemon bremst die Audioausgabe ebenfalls aus!

    - Kann der pigpiod auf eine Teilmenge der GPIOs (hier GPIO4) eingeschränkt werden?

    - hilft es, ein kleines C-Programm zu erstellen, das den GPIO4 ansteuert und mit system(<Pfad>/<Programmdatei>) aus audacious heraus aufgerufen wird?

    - wäre eine andere Lib (wiringPi, bcm2835) evtl. besser geeignet?

    Es ist zum ko... -- äh Mäuse melken!

    schlizbäda

    Edith meint dazu:

    Ich habe pigpio durch wiringPi ersetzt. Um genau zu sein, verwende ich das in wiringPi enthaltene Kommandzeilenprogramm gpio zum Ändern von GPIO4. Erstens war das am schnellsten in den audacious-Quellcode eingebunden (nur der simple Aufruf der Funktion system("gpio ...") aus der <stdlib>) und zweitens (der wichtigere Grund) braucht audacious dazu keine Rootrechte. Und damit schalte ich GPIO4 problemlos, ohne die I²S-Kommunikation zu beeinträchtigen!

    Den von mir geänderten audacious-Code (stable version 3.9) habe ich schon mal vorab als Github-Repository veröffentlicht. Jetzt bin ich gerade dran, noch eine LaTeX-Doku dafür zu verfassen, auf deutsch und auf englisch...

    Was meinst Du mit scanlines?

    Sind die zusätzlich als Schmierage (sorry für die bairisch-französische Wortschöfung) zum eigentlichen Bild da oder erscheinen die anstelle des erwarteten Bildes auf dem Röhrenfernseher? Ist das Stereosignal vollständig vorhanden oder fehlt ein Audiokanal?

    Ich würde zuerst bei der Hardware/Verkabelung suchen: Handelt es sich um ein von der Verarbeitung her vernünftiges und einigermaßen qualitativ hochwertiges vierpoliges Klinkenkabel? Ganz windige Kabel neigen dazu, Störungen einzufangen, die dann das analoge FBAS-Bild verschlechtern...

    Stimmt die Belegung des Kabels mit der Buchsenbelegung des RPi überein? Eine definierte Standardbelegung gibt es für die vierpoligen Klinkenstecker meines Wissens nach nicht. Erschwerend kommt hinzu, dass sich der RPi nicht an die gängigen Quasistandards hält. Da hilft nur, die Dokumentation(en) zu studieren. Ich weiß die jeweiligen Belegungen nicht auswendig, da ich den analogen Audioanschluss des RPi (aus Prinzip) nicht verwende. Siehe auch diesen Thread: Audioprobleme - Rauschen (Analog)

    Auch ich nutze im Wohnzimmer einen RPi 3 B als Kodi-Mediacenter an einem Röhrenfernseher (siehe Link auf meiner Pinnwand). Das FBAS-Videosignal greife ich über eine zweipolige Stiftleiste vom ursprünglichen Einbauplatz der vierpoligen Buchse ab. Das Audiosignal wird bei mir über eine HifiBerry-DAC+-Soundkarte aufbereitet. Alle drei Signale (FBAS, Audio-L, Audio-R) führe ich über einen Scart/Cinch-Adapter zum Röhrenfernseher. Außerdem greife ich über zwei Y-Cinch-Kabel das Audiosignal vom RPi (HifiBerry) nochmals ab, um es meinem guten alten Audioverstärker zuzuführen.

    Funzt einwandfrei und befriedigt meine (zumindest mittelmäßigen) audiophilen Ansprüche. Auch das FBAS-Bild ist (im Rahmen der technischen Möglichkeiten) top:

    - Kein Bildrauschen (Flimmern bzw. Schnee)

    - Keine Verzerrungen

    - Keine irgendwie gearteten Bildstörungen wie man sie von früherTM kennt

    forum-raspberrypi.de/attachment/16599/

    Hier zur Veranschaulichung ein Bild von meinem alten RPi 1 B+, bei dem ich diesen Umbau seinerzeit ebenfalls durchführte und der gerade für GPIO-Versuche (pigpio unter C/C++) auf meinem Basteltisch liegt. Man beachte die entfernte Klinkenbuchse und die eingelötete zweipolige Stiftleiste.

    habe ein upgrade des systems mal durchgeführt doch plötzlich ein knacken auf dem analogen Audio Port bekommen.

    [...]

    Weiss jemand, wie ich dies lösen kann?

    Der analoge Audioausgang des RPi (3,5mm Klinkenbuchse) war noch nie gut. Die Lösung besteht darin, ihn durch einen beliebigen anderen Audioausgang des RPi zu ersetzen:

    * HDMI: Keine weitere Hardware am RPi erforderlich, man benötigt aber Endgeräte, die das können oder ggf. einen HDMI-Audio-Extraktor

    * I²S-Soundkarte wie z.B. die HifiBerry-Derivate

    * USB-Soundkarte


    Nicht vergessen:

    In kodi/xbian muss in den Einstellungen die Audioausgabe auf den neuen Ausgangskanal umgestellt werden.