www.mikrocontroller.net

Forum: Haus & Smart Home Can Calibration Protocol aka CCP, aber auch XCP


Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich benötige Infos über CCP und XCP.
Idealerweise ein direkter Vergleich beider Protokolle hinsichtlich
Nutzbarkeit beim notwendigen Aufwand für die Implementierung in dem
Controller eigenen Betriebssystem.

Für hilfreiche Links bin ich zu Dank verpflichtet.

Grüße Mike

P.S. Google habe ich bereits gequält, wiki ebenso, bin gerade dabei die
Protokolle von ASAM durch zu lesen. Jedoch kristallisiert sich bislang
keine Antwort auf meine oben gestellte Frage.

Autor: Axel Barkow (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau mal auf

www.vector-informatik.de

Gruß,

Axel

Autor: Timo Engelmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier findest Du die XCP-Specs:

http://www.asam.net/03_standards_06.php?memberlogin=

Grüße Timo

Autor: mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

danke für die Infos, die sind leider für mich nicht neu und die Spec
ist recht trocken gehalten. Die hatte ich mir ja bereits zu  beginn
reingezogen...
Durch die allgemeine Formulierung der Spec, sind einige Dinge für mich
nicht wirklich klar.

Kennt jemand vielleicht noch einen Mailingliste, auch ausländische
(solange auf englisch)???

Danke

Autor: Tien (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Mike,

der Unterschied zwischen CCP(=CanCalibrationProtocol)
und XCP ist, wenn mich nicht alles täuscht, im wesentlichen,
dass beim XCP das Übertragungsmedium nicht mehr nur auf Can
festgelegt ist, während bei XCP das Übertragungsmedium auch
Ethernet, FlexRay, Lin, USB, usw. sein darf.

Vermutlich gibt es auch Inhaltliche Unterschiede, als
Anwender der XCP-Messtechnik kann ich dazu aber wenig sagen,
mir ist es wichtig, dass Daten aus dem Steuergerät rauskommen
alles andere ist mir zunächst egal.

Aber bei Vector findest Du auch freien XCP-Sourcecode,
da stecken bestimmt recht viel Info über XCP drin :-)

Grüße Tien

Autor: tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ganz kurz gefaßt: XCP ist als Supermenge des CCP gedacht. Während CCP
den CAN als Physik fest vorschreibt und auch die Befehlsmenge bzw.
Struktur, ist XCP da weiter gefaßt. Der bessere Weg ist vermutlich,
zuerst CCP verstehen lernen, dann mit XCP befassen. Zumal XCP so neu
ist, das es auch industriell noch sogut wie keine verwendungsfähige
Software gibt! (bitten nicht von Fachzeitschriften und Firmenflyern
täuschen lassen!) Bei CCP sieht das ETWAS besser aus! ;-)

Schönen Tag noch,
Thomas

Autor: Tien (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Thomas,

> Zumal XCP so neu
> ist, das es auch industriell noch sogut wie keine verwendungsfähige
> Software gibt! (bitten nicht von Fachzeitschriften und Firmenflyern
> täuschen lassen!) Bei CCP sieht das ETWAS besser aus! ;-)

da muss ich Dir wiedersprechen.
Wir setzen hier in Steuergeräten XCP ein und es gibt
durchaus auch gute funktionelle (wenn auch teure) Tools.

Grüße,
Timo

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Tien,

kann dir da eigentlich beipflichten. Haben uns hier für das XCP 
entschieden, da es neuer ist und CCP am auslaufen ist.

Kannst du mir sagen, wie die ODT´s abgespeichert werden?
Ich mein du schickt dein DAQ Botschaft mit deiner PIDnumber(=ODT), 
anschliesend werden die Adressen aus der ODT gelesen, besser gesagt, die 
Variablen die hinter diesen Adressen stehen (die länge wird natürlich 
mit angeben).
Meiner Meinung nach müssten die ODT in ner Header stehen.
Über Dein Tool wählst du ja nur noch die Variablen aus, die du 
messen/schreiben willst. Oder werden die ODT´s über das A2L File 
gefüttert?
Aber wann sollen hierfür die Daten Übertragen werden?

Danke

noch ein schönes WE
Grüße
:-)

Autor: Tien (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Mike,

ich bin was XCP angeht im wesentlichen Anwender, da
der Code direkt von Vect*r stammt (sowohl ECU, als auch das Tool).
Deshalb bin ich nicht sehr mit dem dahinter liegenden
Mechanismen vertraut - ich kann nur sagen es funktioniert,
und das sogar recht gut.

Trotzdem, hier was zur Technik:
Bei DAQ wird beim Kommunikationsaufbau der ECU mitgeteilt, welche
Adressen in welchem Task übertragen werden sollen.
Die Daten stammen ursprünglich aus dem .elf-File, welches im
XCP Tool dazu dient, das .a2l-File mit den nötigen Adress Infos
zu füttern.

Du kannst generell ohne weitere Vorbereitung im ECU Code jede
global deklarierte Variable mit XCP auslesen.
Du must einzig das a2l-File mit den aktuellen Adressen aus
dem .map oder .elf File füttern und dann kanns los gehen.

Hoffe das war in etwa eine Antwort - oder hab ich die falsch
verstanden.


Grüße Timo

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Timo,

wir implementieren XCP selbst, benutzen Programme (Mastertool und XCP 
Implementierung) von der Konkurrenz von Vect..
Habt ihr den das XCP Protokoll in eueren ECU selbst eingefügt oder vom 
Vect.. Mitarbeiter einfügen lassen?

Wir sind momentan dran, das A2L File "richtig" zu generieren. Das will 
irgendwie nicht, wie wir es wollen.

Der Rest schein t easy zu sein.
Jedoch bereiten mir immernoch die AML Files ->A2L Kopf zerbrechen.

Wie konfiguriert ihr euer A2L File?
zum Beispiel: Granularity von den ODT´s oder Allgemein.

Die ODT sind ja in der ECU abgelegt, ich schätze man wählt im Mastertool 
einfach seine zu messenden Variablen aus, die werden dann in die ODT der 
ECU geschrieben. Von dort aus werden die Variablen referenziert. Dann 
nur noch den Aufruf mit dem Event_Channel in die ECU Task einfügen und 
die Messung kann beginnen...

Grüße Mike

Autor: Tien (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Mike,

> Habt ihr den das XCP Protokoll in eueren ECU selbst eingefügt oder
> vom Vect.. Mitarbeiter einfügen lassen?

In Zusammenarbeit mit dem Vect*r Mitarbeiter. Wobei das
ziemlich schnell ging, die haben ihren Code für den Tricore
in unsere Toolchain eingefügt und dann wurde es mitcompiliert.
Die einzigen Änderungen an unserer SW war die Anpassung der
CAN config und das Hinzufügen der XcpEvent Funktion
in den jeweilgen Tasks. Nach einem halben Tag lief XCP problemlos.

> Wir sind momentan dran, das A2L File "richtig" zu generieren.
> Das will irgendwie nicht, wie wir es wollen.
> Wie konfiguriert ihr euer A2L File?
> zum Beispiel: Granularity von den ODT´s oder Allgemein.

Momentan stehen wir noch ganz am Anfang, d.h. in diesem
Projekt, XCP ist in meiner bisherigen Abteilung bereits
im produktiven Einsatz.
Ziel soll es sein das A2L File direkt aus dem Code und dem
Map File zu generieren. D.h. der Programmierer fügt zu einer
Messtechnisch interessanten Variablen einen Kommentarblock
hinzu, der dann alle nötigen Infos für das A2L File hat.
Ein Codeparser (der noch zu programmieren ist :-) nimmt
diese Kommentare und erzeugt in Verbindung mit dem Map File
das fertige A2L File.

Mal ne Frage, in welcher Firma arbeitest Du, (sofern Du mir das
schreiben magst bzw. darfst)?

Grüße Timo

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Timo,

das ging ja fix mit der Implementierung. Hat euch Vect.. dann mit der 
erstmaligen Erstellung der A2L Datei geholfen?
Wir generieren Code automatisch und dort gibt es eine Unterfunktion um 
ein A2L File zu erzeugen. Hat bislang aber nicht korrekt funktioniert.

Die Implementierung der Grundfunktion macht mir mittlerweile weniger 
Sorgen. Jedoch habe ich halt in gewissen Bereichen Fragen, die 
wahrscheinlich selbstverständlich sind, dass ich nirgends Antworten 
darauf finden kann ;-)

Weiß net, ob es sinnvoll ist in aller Öffentlichkeit den Firmennamen 
bekannt zu machen. Wir sind aber in der Metropolregion Rhein-Neckar.
Mache grad meine Masterarbeit und tue mich an mancher Stelle als 
Elektroniker (etwas) schwer...

Lass mich raten, Du arbeitest entweder Großraum Stuttgart, München, 
Ingolstadt, Franktfurt oder Wolfsburg??? :-)

Wie lange verwendet ihr XCP bereits, bzw wie lange bist du schon damit 
in Berührung? Grundsätzlich würden sich doch die Hauptfunktionen (messen 
und parameter verändern) bestimmt auch anders realisieren. Habt ihr in 
dieser Richtung ausschau gehalten?

Viele Grüße
Mike

Autor: Tien (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Mike,

> Hat euch Vect.. dann mit der
> erstmaligen Erstellung der A2L Datei geholfen?
Das ist mit CAN*ela kein großes Problem, es gibt darin ein
Modul ein a2l File mit ein paar Klicks aus einem Elf-File
oder Map-File zu generieren. Nach erneutem compilieren (d.h.
Adressverschiebung) müssen in diesem Modul nur die Adressen
aktualisiert werden.
Allerdings ist das halt alles "Handarbeit" d.h. ich muss von Hand das
Elf-File ins Tool laden und die Adressen aktualisieren...
Wie bereits geschrieben ist es das Ziel das am Ende eines Builds das
A2L-File automatisch mit generiert wird.

> Lass mich raten, Du arbeitest entweder Großraum Stuttgart, München,
> Ingolstadt, Franktfurt oder Wolfsburg??? :-)

Ja, gut geraten. Meinen Arbeitgeben findest Du ausserdem in so manchem
Hobbykeller und so mancher Küche :-)

> Wie lange verwendet ihr XCP bereits, bzw wie lange bist du schon damit
> in Berührung?

In der Firma bestimmt schon seit Anfang an, ich persönlich
als Anwender nutzte die Messtechnik ca. 3 Jahre in meiner
alten Abteilung und in der neuen Abteilung in der
wir ein neues Steuergerät entwickeln seit ein paar Wochen.
Hier bin ich allerdings eher für die XCP Betreuung und Erstellung
der A2L Files zuständig neben meinem Hauptjob der Kundendiagnose.

> Grundsätzlich würden sich doch die Hauptfunktionen (messen
> und parameter verändern) bestimmt auch anders realisieren.
> Habt ihr in dieser Richtung ausschau gehalten?

Eher nicht, da der Kunde genaue Vorstellungen hat mit welchen
Tools er Messen und Kalibrieren will.

Grüße Tien




Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Tien,

coole Mischung, soviele Städte (kommt man wenigstens rum) und sogar im 
Hobbykeller sowie Küche zu finden. Dachte XCP würde nur im Automotive 
Bereich eingesetzt werden man lernt nie aus

Ich hatte gehört gehabt, es wäre auch über Diagnose (KWP2000) und ganz 
normales flashen möglich. Natürlich dauer das flaschen länger, als eine 
einzige Variable über das Mastertool zu verändern.

Das man mit CAN*ela A2L Files erzeugen kann wusste ich bislang gar 
nicht. Wahrscheinlich ist das aber wieder ne teurer Angelegenheit die 
Software zu beschaffen, dann lieber selbst was Kleines schreiben...
Soviel scheint es ja nicht zu sein...

Grüße Mike

Autor: Tien (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Mike,

> coole Mischung, soviele Städte (kommt man wenigstens rum) und sogar im
> Hobbykeller sowie Küche zu finden. Dachte XCP würde nur im Automotive
> Bereich eingesetzt werden *man lernt nie aus*

Naja, ich dachte bei dem Stichwort Hobbykeller und Küche würde
es klingeln und ich muss Stuttgart nicht extra erwähnen :-)
Ich vermute allerdings XCP wird (noch) nicht in einer Küchenmaschine
oder in einem Akkuschrauber Verwendung finden :-)

> Ich hatte gehört gehabt, es wäre auch über Diagnose (KWP2000) und ganz
> normales flashen möglich. Natürlich dauer das flaschen länger, als eine
> einzige Variable über das Mastertool zu verändern.

Natürlich, aber das ist nicht wirklich praktikabel - es kostet einfach 
zuviel Zeit. Man will ja nach einer Messfahrt direkt im laufenden
Betrieb einen  Parameter verstellen und sofort weiter arbeiten.
Das geht ohne Probleme, wenn diese Parameter beim
Systemstart ins RAM kopiert werden und Du die RAM Werte per XCP änderst.
Erst wenn die Applikation ok ist kopierst Du die Werte in
eine Hex Datei, die dann geflasht wird und somit beim nächsten System
start in der ECU vorliegen.

> Das man mit CAN*ela A2L Files erzeugen kann wusste ich bislang gar
> nicht. Wahrscheinlich ist das aber wieder ne teurer Angelegenheit die
> Software zu beschaffen,
Ist im CAN*ela von Haus aus drin, aber das Tool ist für
Normalsterbliche tatsächlich nicht ganz billig. Allerdings kostet
die Entwicklung eigener Tools und der µC Software natürlich
auch einiges. Und wenn ich sehe wie reibungslos bei uns die Integration
verlief und wie gut der Support des Herstellers ist war es eine gute
Entscheidung.

> dann lieber selbst was Kleines schreiben...
> Soviel scheint es ja nicht zu sein...

Je nachdem was für Ziele man verfolgt. Ich denke die µC SW
ist nicht wirklich das Problem, die PC SW ist da eher
deutlich zeitaufwendiger (Erfassung, Speicherung, Visualisierung, ...)

Grüße Tien


Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Timo,


> dann lieber selbst was Kleines schreiben...
> Soviel scheint es ja nicht zu sein...

Je nachdem was für Ziele man verfolgt. Ich denke die µC SW
ist nicht wirklich das Problem, die PC SW ist da eher
deutlich zeitaufwendiger (Erfassung, Speicherung, Visualisierung, ...)


Damit meinte ich nen Programm, dass anhand Deines MAP Files und Deiner 
Einstellungen selbstständig ein A2L File erzeugt, ohne händisch im A2L 
File Änderungen vornehmen oder auf teure Software zurückgreifen zu 
müssen.

Die Anwendersoftware (Mastertool) zu schreiben würde den zeitlich Rahmen 
sprengen, ausserdem muss man das rad nicht neu erfinden, wenn es nicht 
teuer bezahlt werden will...

Bin mal gespannt wie das noch laufen wird. Wie gesagt die Geschichte mit 
den ODT´s ist mir immernoch ein wenig unklar...

Grüße in die Landeshauptstadt
Mike

Autor: Mitleser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo?

Ist der Thread noch aktiv?

@Tien(Gast): Ich habe eben mit interesse gesehen, das es wohl möglich 
sein soll, mit V*c*o* CANo|ela aus einem map\elf ein a2l zu erzeugen.

Welche Version verwendet ihr??
Wie geht das??


Danke!!!

Autor: Tien (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

hab gerade gemerkt, dass ich mal wieder die vielen
verschiedenen Ve*tor Produkte durcheinander gebracht
habe...

Ich meinte nicht CAN*ela sondern CAN*pe!
In CAN*pe ist ein a2l-Editor enthalten,
mit dem man aus einem map- bzw. elf-File und
zusätzlicher manueller Angaben ein a2l-File erstellen
kann. Dieses a2l-File ist dann der Input für die XCP Messung
in CAN*ela.

Sorry, hoffe ich hab nun niemand allzu durcheinander gebracht.


Grüße Tien

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Es gibt mittlerweile auch einen VariablenEditor von d*pace, entweder in 
ca*desk mit dabei oder als "stand alone" editor.

Ich weiß nur nicht, in wie fern die sache dann passt oder ob es von der 
semantik der AML unterschiede zwischen Ve*tor und d*pace gibt.

asam ist momentan dran einen konverter zu schreiben. AML -> XML!
später sollen dann XML dateien verwendet werden...

Viele Grüße

Autor: Heitzer Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CCP nur basierend auf CAN Bus
beim XCP kannst auch FlexRay,RS232,usw...

Autor: deg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich bin grad dabei einen XCP Slave zu realisieren.
Jedoch sind einige Fragen offen, hoffe auf paar anregungen um die 
Unklarheiten zu beseitigen.

Die größte frage ist das Calibration Page switching

was soll das?:)

Ein Speicher ist aufgeteilt in Sektoren. //OK
Im Speicher gibt es Segmente die unabhängig von den physikalischen 
Grenzen
sind. // das ist auch OK
Jedes Segment beinhaltet Pages, die alle die selbe Adresse beschreiben 
nur mit unterschiedlichen Einstellungen (z.B read/write access) // nicht 
OK

Die Page's dienen dazu um Schreib und Leserechte des Speichers zu 
Verwalten?
Was ist der Sinn des ganzen, den als ein der Application untergeordnetes 
Protokoll soll ich der ECU vorschreiben auf welchen Bereich sie 
zugreifen kann und wie sie drauf zugreifen kann.

Die zweite Frage ist Bezüglich der Calibration commands

Wie verhält sich das ganze mit dem Flash Speicher?
Denn Speicher kann ich nur Sektorweise löschen.
Wenn ich jetzt das byte in der Page X im Sector Y verändern möchte sei 
es eine Konstante. Muss ich den ganzen Sector zwischenspeichern entweder 
im RAM bzw. im gleich großem freien Sector im Flash, dann den Sector Y 
löschen
und bei wieder beschreiben der Pages, die Page X manipulieren. Eine 
andere Lösung sehe ich derzeit nicht :(. Den RAM kann ich glaub ich 
vergessen. Der
größte Sektor beträgt 512 Kbyte

Viele Fragen, wenig Zeit .....

Danke schon mal im Voraus.

Autor: xtratrax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

habe mit großem Interesse die Diskussionen hier verfolgt ...
nur mal von vorn weg, ich bin ein CCP/XCP newbie.
Könnt ihr mir ein gutes/preiswertes evaluation board empfehlen, das XCP 
over CAN kann? Ich würde gern 2-3 controller über CAN miteinander 
verkoppeln und die sollen dann xcp miteinander sprechen. gibt es 
controller/boards lösungen, die den ganzen protokoll-stack schon von 
vorn herein drauf haben (als PC-karten oder extern), oder muss man sie 
selbst mit den entsprechenden binaries bespielen? wie sieht es da aus 
mit betriebssystem-unterstützungen (OSEK)?
vielleicht könnt ihr mir ein paar hints geben und über euere erfahrungen 
berichten ...

danke im voraus.

xtratrax

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@xtratrax:
XCP/CCP setzt auf dem jeweiligen Protokoll (z.B. CAN) auf, d.h. es gibt 
keine zusätzlichen HW Anforderungen. Du musst lediglich das 
entsprechende Protokoll, also CAN, LIN, Most, ... auf der HW zum laufen 
bringen.

Allerdings ist zu deiner Grundidee folgendes zu sagen:
XCP ist ein "Calibration Protocoll", der eigentliche Sinn ist also nicht 
es für die reguläre Kommunikation zwischen verschiedenen Systemen zu 
verwenden, sondern eigentlich nur zur nachträglichen 
Kallibrierung/Applikation/Diagnose. Für reguläre Kommunikation brauchst 
du kein XCP, da reicht die "normale" z.B. CAN Spec völlig aus.

Christian

Autor: xtratrax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

erstmal danke für deine Antwort Christian.

>XCP/CCP setzt auf dem jeweiligen Protokoll (z.B. CAN) auf, d.h. es gibt
>keine zusätzlichen HW Anforderungen. Du musst lediglich das
>entsprechende Protokoll, also CAN, LIN, Most, ... auf der HW zum laufen
>bringen.

Okay, dafür gibt es ja schon CAN-fähige Controller, oder Eval. Boards. 
Allerdings ist eine XCP Implementierung meist nicht drauf, darum auch 
meine Frage: kennt ihr oder könnt ihr mir einen Controller empfehlen, 
der diesen Protokoll-Stack schon vorkonfiguriert drauf hat?

Einige der Beiträge hier erwähnen, dass eine XCP-Implementierung 
(beispielsweise von Vec...) in einem ECU eingefügt worden ist. Diese 
Alternative besteht natürlich auch, wobei ich keine Informationen 
darüber habe wie welche Plattformen unterstützt werden und ob der 
Vorgang reibungslos abläuft. Da hatte ich auf einige Kommentare und 
Hinweise gehofft ;-).


>Allerdings ist zu deiner Grundidee folgendes zu sagen:
>XCP ist ein "Calibration Protocoll", der eigentliche Sinn ist also nicht
>es für die reguläre Kommunikation zwischen verschiedenen Systemen zu
>verwenden, sondern eigentlich nur zur nachträglichen
>Kallibrierung/Applikation/Diagnose. Für reguläre Kommunikation brauchst
>du kein XCP, da reicht die "normale" z.B. CAN Spec völlig aus.

Ja da stimme ich Dir zu. Allerdings möchte ich die "normale" 
CAN-Kommunikation nicht ersetzen. Angedacht ist, dass in bestimmten 
Fällen ein XCP-fähiges Master-Gerät Parameter in ein/mehrere 
Slave-Geräte explizit setzt. Dadurch sollen Berechnungen dieser Geräte 
reseted und neu eingestellt werden. Ich gehe davon aus, dass dieser 
Vorgang unter dem Stichwort "Kalibrierung" läuft und XCP dafür eine 
super Wahl ist.
Für weitere Einwände bin ich jedoch offen.


Viele Grüße,
xtratrax

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.