Guten morgen zusammen,
Ich stehe vor einem vermutlicherweise kleinen Problem. Ich habe hier ein
8poliges Kabel, mit Rundsteckverbindern auf jeder Seite, welches ich auf
Durchgang und Kurzschluss zu benachbarten Pins testen möchte.
Dafür habe einen einen uC über SPI mit einem 74HC595 (Ausgang) und einen
74HC165 (zum einlesen) verwendet.
Die Kommunikation funktioniert auch sehr gut. Zum testen habe ich
einfach die Eingänge vom 165 1 zu 1 an die Ausgänge vom 595 geschlossen
und kann so immer sehen was ich gesendet hab.
Für meinen Durchgangstest würde würde ich eine ´1`von Bit Position 0 auf
Bit Position schieben. Wenn das Kabel in Ordnung ist müsste ich das
gleiche Signal auch Empfangen.
Schematisch dann so:
von Links nach Rechts Pin 8 bis Pin 1
1
"0000'0001" gesendet
2
|||| |||| Kabel
3
"0000'0001" empfangen
4
5
"0000'0010" gesendet
6
|||| |||| Kabel
7
"0000'0010" empfangen
usw.
Jetzt würde ich gerne eine Ausgabe haben, das wenn ich z.b.:
1
"0000'0001" sende
2
|||| |||| Kabel
3
"0000'0011" empfange
das ich dann eine Auswertung bekomme Pin1 mit Pin1 und Pin2 verbunden.
Ich weiß nun garnicht wie ich damit anfangen soll.
--
Bitte zukünftig "ASCII-Art" in die Formatierungstags [ pre ] [ / pre ]
einschließen.
-rufus
Wo ist das Problem? Ein einfaches if(gesendet != empfangen) tut es
nicht? Falls du noch genauer ausgeben möchtest welche Pins
fälschlicherweise verbunden oder nicht verbunden sind kannst du auch die
Daten per XOR kombinieren und überall dort wo du ein gesetzes Bit hast
unterscheiden sich die beiden Variablen.
Jonas Biensack schrieb:> Welche Programmiersprache soll es denn sein?>> Gruß Jonas
Achso in C sollte es sein :D.
Mir fehlt irgendwie der Ansatz wie ich es dann ausgeben könnte das zb.
Pin 5 mit Pin5 und Pin 6 verbunden ist.
Und zwar würde ich gern alle 8 Messungen schnell hintereinander machen
und dann wenn Fehler Auftreten sollten die Fehler an z.b. an einem LCD
ausgegeben werden.
Z.b. Fehler Pin 1 ist mit Pin 1 und Pin 2 verbunden
Oder Pin 3 ist mit Pin 4 5 6 verbunden.
Oder vieleicht könnte man auch eine Vorgabe hinterlegen.
Z.B.
Pin 7 und 8 sind immer zusammen auf Masse gelegt das heisst bei der Test
sequenz von
"0100'0000" gesendet
und
"1000'0000" gesendet
Empfange ich immer
"1100'0000" empfangen
Aber das wäre erst mal für die zukunft. Erstmal die leichten Probleme
lösen
Geht es um Fehleranalyse bei Netzwerkleitungen? Wenn ja gibts bei Pollin
für ich meine unter 10 EUR ein Testgerät, das Verdrahtungsfehler
erkennt.
Ok, Crosstalk etc findet das natürlich nicht, aber deine Lösung ja auch
nicht ;-)
> Mir fehlt irgendwie der Ansatz wie ich es dann ausgeben könnte> das zb. Pin 5 mit Pin5 und Pin 6 verbunden ist.
Ja nun.
Setzen wir voraus, dass Du mit einem XOR den ausgegebenen Wert und den
wieder eingelesenen Wert verknüpft hast, dann ergibt sich bei Deinem
Beispiel:
"0000'0001" sende
|||| |||| Kabel
"0000'0011" empfange
XOR
0000 0010
Es ist also das Bit 1 gesetzt, das der Pin Nummer 2 entspricht.
Die Systematik dieses Ergebnisses sieht so aus:
0000 0001 1
0000 0010 2
0000 0100 3
0000 1000 4
etc.
Ein Teilschritt wäre, das am weitesten links stehende gesetzte Bit zu
ermitteln. Tatsächlich finden sich im Internet unter "finding leftmost
bit set" mehrere Treffer (und hier im Forum wurde das auch schon
diskutiert - ich finde den Thread nur gerade nicht).
Siehe also hier: http://codeforces.com/blog/entry/10330
insbesondere den Java-Code, den Du aber noch für 8 Bit Werte etwas
verkürzen kannst.
Jonas Biensack schrieb:> if (!inputport & 2^pin2 && pin != pin2)
^^^^^^
2 XOR pin2....???? Was soll das denn sein?
Das ^ ist kein "Hoch"-Operator! Warum postest Du ungetesteten Code? Um
den Thread-Ersteller zu verwirren und vollkommen aufs falsche Gleis zu
führen?
P.S.
Zudem solltest Du mal im C-Buch etwas über Prioritäten von Operatoren
nachlesen. Dein Code ist vollkommener Blödsinn.
Sorry.
OK. Das löst zwar die aufgabenstellung des Posters.
Für einen Test ist das allerdings noch etwas zu kurz gedacht, was
allerdings die Schuld des TO ist, denn er hat da zu kurz gedacht. Es
gibt ja auch noch andere Fehler wie zb, dass ein Kabelbruch verhindert,
dass die 1 überhaupt auf der richtigen Leitung durchkommt.
Die einfachste Strategie ist immer noch:
Leg ein Byte auf den Port, lies am Eingang ein Byte und dort wo sich die
beiden Bytes unterscheiden, dort gibt es ein Problem.
Selbst wenn man jetzt mit den Bitoperationen nicht so auf du und du
steht, ist das relativ einfach zu lösen. Im schlimmsten Fall mit 8
Bitvergleichen. Mir scheint da soll wieder mal wer ein Programm
schreiben, der von den banalsten Grundlagen keine Ahnung hat bzw.
fehlendes Verständnis noch nicht mal durch etwas Phantasie ausgleichen
kann.
Karl Heinz schrieb:> Selbst wenn man jetzt mit den Bitoperationen nicht so auf du und du> steht, ist das relativ einfach zu lösen. Im schlimmsten Fall mit 8> Bitvergleichen. Mir scheint da soll wieder mal wer ein Programm> schreiben, der von den banalsten Grundlagen keine Ahnung hat bzw.> fehlendes Verständnis noch nicht mal durch etwas Phantasie ausgleichen> kann.
Hallo,
Nee das Programm soll mir keiner schreiben ;) das würde ich gerne selbst
machen.
Die SPI Kommunikation mit den beiden Bausteinen habe ich ja schon
gemacht :)
Nur fehlt mir der Ansatz wie der Rest realisiert werden kann.
Ich könnte natürlich etliche IF schleifen machen die dann alles
durchrattern. Aber ich bin auch der suche nach einem Denk Ansatz um es
einfach Universell zu halten. Um es zum Beispiel "schnell" auf ein 40
poligen Stecker aufzurüsten.
Die Frage ist auch ob man einfach einen "Belegungsplan" in ein Array
schieben sollte.
Zum Beispiel habe ich ein 8 Poliges Kabel wo immer Pin 4 und 5 getauscht
sind und Pin 8 und 7 führen ein und das selbe Signal.
Da könnte ich mir ja ein Array bauen in wo das eingelesene mit dem
Arraywert und dem Ausgebebyte verglichen wird. Damit könnte ich dann
zwar schnell sagen ob das Kabel richtig ist aber die Auswertung wenn es
falsch wäre ist damit noch nicht realisiert.
Aber ich vermute das ich damit den speicher total zu hacke.
Ich muss vorweg sagen das ich noch nicht so viel mit C gemacht habe und
es mir sehr leid tut wenn ich ganz blöde Fragen stelle, aber ich
versuche es ja zu lernen. Also habt bitte ein wenig nachsicht.
=)
Billy schrieb:> Nur fehlt mir der Ansatz wie der Rest realisiert werden kann.> Ich könnte natürlich etliche IF schleifen machen
Es gibt keine if-"Schleifen". Das Markenzeichen einer Schleife ist die
Widerholung. Darum heisst es Schleife. Ein if wiederholt nichts. Ein if
trifft eine Auswahl.
> die dann alles> durchrattern. Aber ich bin auch der suche nach einem Denk Ansatz um es> einfach Universell zu halten. Um es zum Beispiel "schnell" auf ein 40> poligen Stecker aufzurüsten.
Wenn du das in den letzten Stunden mal durchgerattert hättest, dann wäre
dir vielleicht was aufgefallen.
Denn der Durchrattercode hätte navi geschrieben so ausgesehen
1
if((input&(1<<0))!=(output&(1<<0)))
2
lcd_puts("Fehler im Bit 0");
3
4
if((input&(1<<1))!=(output&(1<<1)))
5
lcd_puts("Fehler im Bit 1");
6
7
if((input&(1<<2))!=(output&(1<<2)))
8
lcd_puts("Fehler im Bit 2");
9
10
if((input&(1<<3))!=(output&(1<<3)))
11
lcd_puts("Fehler im Bit 3");
12
13
...
und da sieht man jetzt sofort, dass es eigentlich immer der gleiche Code
ist, und sich nur eine Zahl zwischen den Zeilen ändert. Hmm. Das ist
aber schon mal der perfekte Ansatz für eine for-Schleife
1
for(BitNr=0;BitNr<8;++BitNr)
2
{
3
if((input&(1<<BitNr))!=(output&(1<<BitNr)))
4
{
5
sprintf(buffer,"Fehler im Bit %d",(int)BitNr);
6
lcd_puts(buffer);
7
}
8
}
Ich denke, sowas kann man dir durchaus zumuten, dass du da alleine drauf
kommst.
Und PS: Die Ausgabe auf einem LCD (TextLCD?) könnte durchaus zu einem
Problem werden. Denn bei den herkömmlichen LCD hast du nicht viel Platz.
Wie realisierst du denn die Ausgabe, wenn ein Kabel 5 fehlerhafte Adern
besitzt?
Darüber würde ich als allererstes mal nachdenken, wie ich die Ausgabe
mache. Denn so toll auch eine Ausgabe ala "Ader 1 mit Ader 2 verbunden
ist", so viel Platz nimmt sie auch weg.
> Die Frage ist auch ob man einfach einen "Belegungsplan" in ein Array> schieben sollte.> Zum Beispiel habe ich ein 8 Poliges Kabel wo immer Pin 4 und 5 getauscht> sind und Pin 8 und 7 führen ein und das selbe Signal.> Da könnte ich mir ja ein Array bauen in wo das eingelesene mit dem> Arraywert und dem Ausgebebyte verglichen wird.
Ja. Könnte man
> Damit könnte ich dann> zwar schnell sagen ob das Kabel richtig ist aber die Auswertung wenn es> falsch wäre ist damit noch nicht realisiert.
Dann lass dir zu dem Thema was einfallen!
Du bist der Entwickler.
> Aber ich vermute das ich damit den speicher total zu hacke.
Hast du es schon probiert?
Mit Vermutungen kommt man nicht weit. Ausprobieren heisst die Devise.
Machen!
Mal dir halt mal auf Papier auf, was du alles detektieren willst. Dann
sitzt du dich hin und entwickelst einen Plan, WIE du das detektieren
kannst (einfach mal in Umgangssprache formulieren). Dazu ist es zum
Beispiel notwendig, dass du in deinen Beispielen allgemeine Regeln
festmachst.
Aus deinem Beispiel aus dem Ursprungsposting beispielsweise:
Wenn Bit 0 auf 1 gesetzt ist UND alle anderen Bits 0 sind, dann muss es
am Ausgang so sein, dass dort ebenfalls Bit 0 auf 1 rauskommt UND alle
anderen Bits 0 sind. Wenn Bit 0 zwar 1 ist, aber irgendein anderes Bit
ebenfalls 1 ist, dann liegt die Vermutung nahe, dass es hier wohl einen
Kurzschluss gibt zwischen den beiden Adern gibt.
Dann sinnierst du ein wenig und kommst drauf, dass dasselbe nicht nur
für Bit 0 gilt, sondern eigentlich für alle Bits. Sind sie am Eingang
auf 1 dann müssen sie am Ausgang auch auf 1 sein. Alle anderen Bits
müssen hingegen auf 0 sein.
Pfah. Und schon hast du eine Regel, die dir diesen Fall abdeckt und
erkennt.
Jetzt denkst du dir noch andere Fehlerszenarien aus und siehst zu, dass
du ebenfalls die Regelmässigkeit dahinter erkennst und formulierst
diese.
Du wirst vielleicht Regeln haben, die dir sagen, wann eine Ader
unterbrochen ist. Oder eben Regeln auf Kurzschluss zweier Adern. Oder
Regeln die dir eine Überkreuzung 2-er Adern anzeigen. Oder ....
Und dann implementierst du deinen Plan. Regel für Regel. Eine nach der
anderen. Und mit jeder implementierten Regel mehr, kann dein Tester
weitere Fehlerfälle entdecken. Unnötig zu sagen, dass natürllich jede
Regel einzeln, gleich nachdem sie implementiert wurde, ausgiebig
getestet wird. Und zwar in beiden Richtungen: schlägt sie wirklich nicht
an, wenn es keinen Fehler gibt? Und: Schlägt sie an, wenn der Fehlerfall
tatsächlich vorliegt.
Das schlimmste was du tun kannst, ist aber wie die Maus vor der Schlange
zu sitzen und nicht weiter zu wissen. Schrittweises Vorgehen, bei dem
man sich immer nur auf eine derartige Regel konzentriert, vermeidet das.
Und der Rest ist einfach nur ein ganzer Haufen Schleifen, ein ganzer
Haufen Bitvergleiche und ein ganzer Haufen Ausgabeoperationen.
Karl Heinz schrieb:> Und PS: Die Ausgabe auf einem LCD (TextLCD?) könnte durchaus zu einem> Problem werden. Denn bei den herkömmlichen LCD hast du nicht viel Platz.> Wie realisierst du denn die Ausgabe, wenn ein Kabel 5 fehlerhafte Adern> besitzt?> Darüber würde ich als allererstes mal nachdenken, wie ich die Ausgabe> mache. Denn so toll auch eine Ausgabe ala "Ader 1 mit Ader 2 verbunden> ist", so viel Platz nimmt sie auch weg.
Als Aller erstes vielen Dank Karl Heinz für deinen ausführlichen Post,
dort kann ich jede Menge Informationen gewinnen.
Ich werde mich direkt mal dransetzten und mir alle benötigten
Informationen Aufzeichnen.
Ja ein 4x20 LCD habe ich momentan auch am laufen dort sende ich mir
diverse Debug-Informationen.
Ich muss einfach strukturierter an die Sachen gehen. Einfach schritt für
schritt deine Regeln befolgen dann sollte es klappen.
Ich habe zuvor irgendwie gar nicht den Berg überblicken können und
wusste nicht wo ich anfangen soll. Das war irgendwie mein Problem.
Nochmals vielen Dank. Ich werde direkt versuchen die Sachen umzusetzten.
Sollte noch Fragen auftauchen melde ich mich noch einmal ;-)
Viele Grüße
>Es>gibt ja auch noch andere Fehler wie zb, dass ein Kabelbruch verhindert,>dass die 1 überhaupt auf der richtigen Leitung durchkommt.
Das prüft diese Abfrage:
Jetzt muss ich aber ein wenig grinsen.
Ich habe genau den Ansatz genannt, der sogar so allgemein ist, dass er
nicht nur für Kurzschlüsse der Leitungen untereinander, sondern mit Vcc
und Gnd und auch den Fall des Tests mit Low-Pegel erfasst. XOR und dann
die gesetzten Bits ermitteln (wobei eigentlich egal ist, wie man das
macht - durchprobieren geht natürlich auch - da die Berechnung des
gesetzten Bits leider nicht sehr effizient auf einem AVR ist) aber die
Berechnung des obersten gesetzten Bits ist eine gute Möglichkeit.
Aber meine Erklärung hatte den Nachteil, dass man das erstmal
durchdenken und mal was ausprobieren musste. So eine Schande.
Aber nein, nicht nur, dass dann jibi erstmal eine Durchprobier-Lösung
postet, ohne zu erklären, welche Einschränkungen sie mit sich bringte.
(Geht nur mit Test auf 1en).
Da muss erstmal Karl Heinz kommen und alles nochmal einzeln erklären -
teilweise Dinge die schon gesagt wurden -, damit es "funkt". Ich mag
seine Erklärungen und auch das sie wirklich detailliert sind, aber sie
haben den Nachteil, dass die Fragesteller (und das schon seit langem)
daran gewöhnt werden, alles vorgekaut zu bekommen. In leichten Häppchen,
verdaulich und ohne das irgendjemand nochmal eigene Geisteskraft
aufbringen muss.
Karl Heinz schreibt zwar auch, dass der TO selbst mal nachdenken soll,
aber erst nachdem er eigentlich schon alle Mühe selbst auf sich genommen
hat.
So hat sich hier das Konsum-Denken in Bezug auf das Wissen eingebürgert.
Wirklich Schade, finde ich.
Bitflüsterer schrieb:> So hat sich hier das Konsum-Denken in Bezug auf das Wissen eingebürgert.> Wirklich Schade, finde ich.
Es tut mir Leid ich wollte dir nicht auf den Schlips treten aber ich
habe ehrlich genau nicht verstanden wofür ich die Xor bzw wofür ich die
"finding leftmost bit set" benutzten könnte.
Wie gesagt ich stehe erst ganz am Anfang und ich probiere noch viele
Sachen.
Vieleicht kommt ja dein Code Vorschlag auch noch dran. =)
Einen schönen Abend wünsche ich noch
Habt ihr mal daran gedacht, daß bei Aderkurzschlüssen Ausgangsportpins
gegenseitig kurzgeschlossen werden? M.E. muß man beim Kabeltesten so
vorgehen, daß beim treibenden Port immer nur ein Bit auf Ausgang
programmiert wird, alle anderen auf Eingang. Beim Empfängerport kommen
umschaltbar Pulldowns bzw. Pullups hin. Dann wird am Treiberport Bit für
Bit aktiv geschaltet und 0/1 gesendet, am Empfängerport zw. pulldown und
Pullup umgeschaltet. Damit erkennt man Kurzschlüsse und Unterbrechungen.
Das geht mit einem SPI-getriebenen Ausgangsport so nicht, da muß es ein
echter Prozessorport sein. Oder man realisiert die Datadirectionfunktion
mit einem zweiten SPI-Port, das ist recht aufwendig.
Man kann auch ganz einfach entsprechende Serienwiderstände an den
Ausgangspins vorsehen, an denen im Falle eines Kurzschlusses die
Spannung abfallen kann.
@Bitflüsterer
Ich komm nicht umhin, dir in der Sache Recht zu geben. Leider sehen wir
es hier im Forum sehr oft, dass Leute an ein Projekt rangehen, die noch
lange nicht soweit sind. Die übliche "Lehrzeit", in der man sich erst
mal mit den notwendigen Grundlagen beschäftigt, wird nur allzuoft
übersprungen bzw. es finden oft grobe Unterschätzungen der
Schwierigkeiten in der Problemstellung gepaart mit einer Überschätzung
des eigenen Könnens statt. Woran das liegt, dass das immer häufiger
auftritt kann ich allerdings auch nicht sagen.
@ Karl Heinz
Wenn ich das so mit meiner Anfangszeit vergleiche, in der es noch kein
Internet gab, so stelle ich fest, dass auch damals die Ambitionen größer
waren als die Fähigkeiten. Das betrifft auch mich selbst. Das alleine
ist eigentlich nicht entscheidend - meiner Meinung nach.
Allerdings war es schon deswegen, weil eben der oder diejenigen, die
schon weiter waren als man selbst, einfach nicht immer verfügbar waren,
einfach schwer möglich, andauernd Fragen zu stellen. Da blieb einem nur,
selbst zu "forschen" oder auf den nächsten Tag, ggf. den nächsten Montag
zu warten zu dem man den netten Freak in der Berufsschule wieder traf,
um ihn erneut mit Fragen zu bombardieren. Das alleine ist aber wiederum
nicht entscheidend.
Ich erinnere mich, dass ich mir einmal von "meinem Freak" einen Ausdruck
des Commodore-Basic (in Assembler) erbat, weil ich herausfinden wollte,
wie so ein BASIC-Interpreter nun eigentlich genau funktioniert. Zu dem
Zeitpunkt kannte ich nur einige Assembler-Befehle des 6502.
Adressierungsarten waren mir ein Begriff, aber ich kannte nicht alle. So
saß ich auf dem Weg von und zur Lehre in der Bahn - meine Fahrzeit
betrug über eine Stunde pro Strecke - mit einem Riesenstapel
Traktorpapier und hangelte mich die JMP's und JSR's entlang. Das scheint
mir, ein wichtiger Punkt zu sein, dass man selbst wirkliche
Anstrengungen auf sich nimmt um zu verstehen.
Und dann erst habe ich meine "Entdeckungen" mit meinem Kumpel diskutiert
und weiterführende Fragen gestellt. Ich meine mich auch zu erinnern,
dass es vorkam, dass mich seine Erklärungen nicht befriedigten - oft
weil ich sie schlicht nicht verstand. Wie ein Interpreter nun genau
funktioniert, war so ein Fall. Da habe ich das eben selbst
nachvollzogen. Ich fand es wahnsinnig spannend. Das scheint mir ein
wesentlicher Punkt zu sein.
An meiner Berufsschule damals, gab es ungeführ Fünf (von geschätzten
200-300 Schülern), die sich mit Computern beschäftigten. Das scheint
heute wenig zu sein - und ist es es auch. Aber damals war das noch
"esotherisches" Wissen. Hochkompliziert. Was zum "Gehirnverbiegen". Das
gab schon mal eine Auslese, denn wer Dich dann wirklich mit Fragen
gelöchert hat, war ein genauso verspinnerter (und schüchterner)
Bücherwurm wie man selbst.
Die wenigen Ausnahmen, die sich die Zugehörigkeit zu wenigstens einer
Gruppe und dann noch zu so einer "elitären" versprachen ohne am Thema
interessiert zu sein, wurden recht schnelle ausgesiebt. Sie zeigten
nämlich schon nach wenigen Tagen, dass sie keinerlei eigene Fortschritte
machen konnten, nichts selbst versuchten - nichtmal von Fehlschlägen
berichten konnten. Und keine eigenen Entdeckungen von Büchern oder Läden
machten.
Wer nun wirklich nicht aufgeben wollte sich einen guten Fuß bei den
Computer-Nerds zu machen, der wurde dann nach einer Weile einfach
abgeblockt. Das war nicht weiter schwer, denn da wir uns sowieso über
unser Lieblingsthema unterhielten und derjenige kaum Ahnung hatte,
verstand er einfach nur Bahnhof. Und nach einer Weile wurde es ihm dann
langweilig, zuzuhören. Wenn aber jemand offensichtlich bemüht war sich
in das Thema einzuarbeiten - was sich alleine schon darin zeigte, dass
er die Begriffe anzuwenden lernte - dann war es überhaupt kein Problem,
jedes noch so triviale Thema zu erklären. Durchaus auch mehrmals.
Man kann die Verhältnisse dieser Zeit sicher nicht vollständig auf heute
übertragen. Mit zwei Ausnahmen gibt es aber nach wie vor die selben
Motivationen. Wir sind uns vielleicht einig, dass die relative Zahl der
leidenschaftlich Interessierten ungefähr gleich geblieben ist oder
jedenfalls nicht bedeutend zugenommen hat. Dazugekommen ist, die große
Zahl derjenigen von denen die Beschäftigung mit Computern (z.B. von der
Schule, den Eltern etc.) gefordert wird ohne das sie eigentlich
Interesse dafür haben. Die stellt den Löwenanteil derjenigen, die
einfach nur Code wollen und solange behaupten, sie verstünden es nicht,
bis man einfach den Code hinschreibt und es aufgibt, zu erklären, welche
Grundlagen dazu gehören ihn selbst zu schreiben. Der zweite völlig neue
große Teil will ein Projekt realisieren, hat aber eigentlich auch keine
Ahnung wie und stellt sich als begriffsstutzigen Interessierten oder
wenigstens als Gezwungenen hin und will letztlich auch nur Code.
Meiner Ansicht nach hat, die Gruppe derjenigen, die sich mit dem Thema
aus sozialen Gründen beschäftigen relativ am stärksten zugenommen. Das
Phänomen der Trolle spricht dafür. Das Internet bietet eine einfache
Möglichkeit jedermann zu jederzeit auf jede Weise (ob auf angemessene
oder unangemessene Weise) zu jedem Thema anszusprechen. Das dazu
kongruente Phänomen ist die Zunahme der Anzahl derjenigen, die, entweder
durchaus kompetent auf jeden Fall zeigen müssen, das sie etwas wissen
oder, mit weitaus geringeren Kenntnissen, irgendwie immer was beitragen
zu müssen glauben - ob es nun nützlich ist oder nicht.
Ohne Dir daraus einen persönlichen Vorwurf machen zu wollen, meine ich
feststellen zu können, dass Du Dich (im wesentlichen) immer noch
verhälst, als wenn die Verhältnisse von damals herrschen. Du erklärst
jedem und allen jeden beliebigen noch so trivialen ("Mist", hätte ich
beinahe geschrieben) Punkt und fügst teilweise sehr elaborierten Code
hinzu.
Damit aber unterstützt Du alle der genannten Gruppen gleichermaßen. Ich
weiß ja nicht, ob Du auch so begonnen hast, oder ob Du dich eher so
verhalten hast, wie ich es oben beschrieb.
Die Einschränkung "im wesentlichen", die ich oben eingefügt habe, hielt
ich für notwendig, weil Du durchaus auch bei manchen Gelegenheiten
einmal Deinen Unmut, mit Argumenten, die den meinen verwandt sind,
geäussert hast.
Ich muss auch zugegeben, dass die Haltung, jeden gleich zu behandeln,
philosophisch und ethisch gesehen, durchaus etwas für sich hat. So ganz
ohne inneren Widerspruch fühle ich mich auch nicht darin, was ich hier
vertrete. Wenn ich für mich entscheiden soll, wie ich darin handle, dann
komme ich aber zu dem Schluß, dass ich mich auf soetwas wie "den
kleinsten gemeinsamen Nenner" beschränken müsste, würde ich jeden gleich
behandeln wollen. Du wählst da eine andere Alternative (meine ich): Du
behandelst jeden gleich, unter Aufwendung des Maximums (oder jedenfalls
eines sehr hohen Maßes) Deiner Kenntnisse und Fähigkeiten in Bezug auf
Informatik.
Letztlich ist es Deine und meine persönliche Angelegenheit. Und indem es
die persönliche Angelegenheit jedes Einzelnen hier ist, formt sich das
Forum.
Die Rechtschreibung bzw. Groß- Kleinschreibung wird hier im Forum nicht
konsequent verlangt.
Kritisiere ich die Rechtschreibung, dann kommt es nicht so darauf an.
Hauptsache man kann es lesen. Oder ich bin ein Erbsenzähler. Oder ich
will mich nur profilieren. Nichts daran ist völlig falsch. Aber in
meinem idealen Forum kann man einen Text flüssig lesen und es treten
keine Widersprüche durch allein durch Rechtschreibfehler auf. Das man
sich immer wieder mal vertippt, ist für mich akzeptabel; auch das
Nicht-Muttersprachler viele solche Fehler machen - von einem ignorantem
Umgang damit kann man das aber in der Regel recht klar unterscheiden.
Die korrekte Verwendung von Fachbegriffen wird hier im Forum nicht
durchgesetzt. Verbessere ich das, so kommt wieder das "Hauptsache Du
weisst was ich meine" oder Erbsenzähler-Argumente. (Es sind immer wieder
dieselben Gegenargumente.) Dabei wird verkannt oder sogar geleugnet, das
man einen falsch verwendeten Fachbegriff nicht "trotzdem" verstehen
kann, sondern das man ihn als Leser erst durch den korrekten Begriff
ersetzen muss. Eine grundsätzlich andere geistige Operation. Und
wiederum wird verkannt, das dieses Ersetzen nicht nur von der Fähigkeit
des Lesers, sondern von dem Umfang und dem Informationsgehalt des Textes
abhängt. Beides liegt aber in der Verantwortung des Autors.
In beidem zeigt sich darüber hinaus ein bemerkenswerter Widerspruch: Es
wird zwar implizit anerkannt, das Wissen relevant ist, in dem man Fragen
stellt, gleichzeitig aber wird das Faktum bestritten, wenn nicht
ausdrücklich dann in dem man es ignoriert (und falsch schreibt).
In meinem idealen Forum, werden Begriffe korrekt verwendet. Man kann
notfalls den Begriff nachschlagen und sich den Sinn des Texts selbst
erschliessen weil er korrekt verwendet wurde. Das gerade ein Anfänger
sich in der Bedeutung eines Begriffes schlicht irrt, Begriffe falsch
anwendet oder falsch auf einen anderen Themenkreis überträgt ist
akzeptabel.
Es ist ohnehin für den Leser fast nicht zu entscheiden, aus welchen
Gründen das geschieht. Aber Korrekturen von Anderen werden (in meinem
idealen Forum) widerspruchslos (es sei denn die Korrektur selbst ist
fehlerhaft), optional mit einer Paraphrasierung bzw. Erläuterung und mit
Dankbarkeit entgegengenommen und sofort verwendet.
In meinem idealen Forum werden Fragen vollständig (im wesentlichen meine
ich damit: nach den Regeln der Netiquette) formuliert. Man muss in der
Regel keine inhaltlichen Fragen dazu stellen: Z.B. nach Quellcode oder
Schaltplan. Selbst Schüler, die hier so oft aufschlagen, erhalten im
Normalfall eine Aufgabenstellung, ggf. einen Lösungsweg oder Vorschlag
dafür und sind aufgefordert ihre Vorgehensweise zu begründen oder zu
klären an welchem Punkt ihre Ergebnisse von den erwarteten abweichen.
Idealerweise enthalten sie auch einen Versuch, den Punkt, der das
verursacht im Text oder Bild zu zeigen und einen Erklärungsversuch,
welcher Kette aus Ursache und Wirkung zu dem Fehlverhalten führt.
Da aber gerade inhaltliche Fragen im Forum, letztlich gerade deswegen
gestellt werden, weil einer dieser letzten idealen Punkte nicht erfüllt
werden kann (wobei Quellcode und Schaltplan selbst bei noch so großem
Unvermögen eigentlich immer möglich sind) ist hier die größte
Sensibilität der Leser gefragt. Es ist zweifellos recht einfach,
festzustellen ob der Versuch von Erklärungen einfach nur fehlt. Ein
fehlerhafter Versuch ist aber gerade der Zweck dieses Forums - deswegen
ist die sensible Unterscheidung zwischen einfach nur fehlgeschlagenen
Erklärungsversuchen und solchen die, nach Würdigung aller Umstände,
lediglich auf die fahrlässige Unterlassung eigener Beühungen um das
Thema zurückzuführen sind. Wer das liest, wird viele Einwendungen, viele
Relativierungen anführen wollen, die im einzelnen vermutlich berechtigt
sein werden. Deswegen würde ich an dieser Stelle eher nicht, als
überhaupt eingreifen. Aber interessant und bemerkenswert ist, das die
wenigsten Threads überhaupt solche eigenen Versuche der Erklärung
enthalten.
In meinem idealen Forum sind Beiträge oder Teile davon entweder klar als
komisch oder auch satirisch gemeint zu verstehen. (Notfalls unter
Verwendung von Pseudo-Tags wie es hier ja auch oft schon gemacht wird).
Ansonsten sind sie vollständig sachlich. Jede, auch andeutungsweise,
Herabsetzung der Person, der Fragestellung oder ihrer Art und Weise oder
der Sache selbst, unterbleiben. Insbesondere gibt es keine
rethorisch-ironische Fragen, höhnische Bemerkungen oder Interjektionen
wie "Quatsch", "Blödsinn" etc. (Leider muss ich mir selbst da auch
einiges vorwerfen, aber ich habe mich bemüht, mich zu bessern). Der
Geist des Forums ist die gegenseitige Hilfe sowie die fruchtbare
Diskussion. Zweifellos sind die Entscheidungen auf diesem Gebiet
manchmal sehr subtiler Art. Die menschlichen Verletzungen die man sich
auf diese Weise zufügen kann, sind aber in ihrer Wirkung überhaupt nicht
und im Zweifel nicht hoch genug einzuschätzen. Deswegen wird auch der
Zweifelsfall so entschieden, als wenn eine unsachliche und verletzende
Abschweifung vorliegt. Im Falle einer nicht völlig klaren Entscheidung
wird kurz erklärt, dass die fragliche Wendung nicht eindeutig negativ
ist, aber dennoch Zweifel aufwirft.
Das war's aus meinem Forums-Utopia.
Du fragtest, Karl Heinz, woher diese Entwicklung, die wir beide beklagen
kommt. Vielleicht kommen auch Dir, die von mir genannten idealen Punkte
wünschenswert vor (wenigstens in den wesentlichen Teilen). Kehre ich die
Punkte einmal um, so ergibt sich die Antwort: Wenn Postings mit einer
großen Anzahl von Rechtschreibfehlern nicht unmittelbar (sobald ein Mod
dazu Zeit hat und unter Hinweis auf den Grund) gelöscht (ich stelle mir
vor, das anstelle des Beitrags der Löschhinweis steht) werden, gibt es
sie weiterhin. Wenn Postings, ohne achtsamen Umgang mit Begriffen (oder
wenigstens dem Versuch dazu) nicht sofort gelöscht werden (wieder unter
Angabe des Grundes) wird es sie weiterhin geben. Wenn Postings unter
offensichtlicher Ignoranz der Netiquette nicht sofort gelöscht werden,
gibt es sie weiter. Wenn Postings mit offensiven Angriffen und
zweideutigen Bemerkungen nicht sofort gelöscht werden, gibt es sie immer
wieder.
Da das aber nicht geschieht und lange Zeit nicht geschehen ist, ist das
Forum so geworden wie es jetzt ist.
Bitflüsterer schrieb:> Damit aber unterstützt Du alle der genannten Gruppen gleichermaßen. Ich> weiß ja nicht, ob Du auch so begonnen hast,
Ich hab im Prinzip (mit einem Kumpel) genau so begonnen, wie du auch.
Nur dass wir niemanden zum fragen hatten :-)
Dafür haben wir jeden Artikel, jeden Fetzen Papier, den wir nur irgendwo
her kriegen konnten gelesen. Das erste viertel Jahr war praktisch nur
'Bahnhof'. Gelesen haben wir zuerst die 'chip' und dann beginnend mit
Ausgabe 1 die c't. Und natürlich hab ich in allen umliegenden
Buchhandlungen alle Bücher gekannt. Besonders die vom Rolf Dieter Klein
:-)
Das erste 'Jahr' hatten wir nur Taschenrechner (TI-58, später HP41),
unsere ersten BASIC Programme schrieben wir auf Papier und der jeweils
andere hat korrigiert. Wir hatten keinen Zugang zu einem Computer. Den
kriegten wir erst im nächsten Jahr in Form einer PDP-8. erstes größeres
Programm: symbolisches Differenzieren (in BASIC!). 2 Jahre später gings
dann auf die Uni INformatik studieren.
> Vielleicht kommen auch Dir, die von mir genannten idealen Punkte wünschenswert
vor (wenigstens in den wesentlichen Teilen).
Oh ja!
Und ich hab mir da auch schon einiges anhören müssen :-)
@ Karl Heinz
> Dafür haben wir jeden Artikel, jeden Fetzen Papier, den wir nur> irgendwo her kriegen konnten gelesen.
Ja, damals waren sogar die Anzeigen für uns lehrreich. Nicht soviel
Marketing-Geschwafel :-)
Bis auf die genannten Zeitschriften war alles sonst auf Englisch. So
hatte ich denn einen "richtigen" Grund Englisch zu lernen.
> Und ich hab mir da auch schon einiges anhören müssen :-)
Das fürchte ich auch. <spitze><Zensiert></spitze>
:D
Thread beobachten
Seitenaufteilung abschalten