ENTWARNUNG vor überkompli....., 2.Teil: Zeitdiskussion MC22 ........
- Ersteller Gast_1336
- Erstellt am
k_wimmer
User
Hallo Rudy,
im Grunde hast Du ja Recht, nur ist der Programmierer einer Firmware dazu verpflichtet die Software so zu gestalten, dass eben solche Systemüberlastenden Möglichkeiten (auch durch evtl. Falscheingaben) gar nicht erst genutzt werden können!
1. Alle Features die in einer Anleitung drinstehen müssen funktionieren
2. Alle Eingaben die in einer Software gemacht wurden, die nicht dem Handbuch entsprechen dürfen keine Ausfälle verursachen!
In diesem Fall würde ich sagen, dass die Programmierung nicht vollständig durchdacht und getestet ist.
Ich weiss allerdings auch, dass Software (auch im versicherungstechn. Sinn) als nicht zu 100% testbar gilt.
Ich sehe bei den heutigen Sendern viel eher das Problem darin, dass der Jenige der das Modell programmiert und eingestellt hat meistens durch seine eigenen Programmierungen nicht mehr durchsteigt, dann irgendwelche Verknüpfungen nicht richtig beseitigt, und bei irgendwelchen Zeitabläufen oder in einem anderen Flugzustand dann halt dadurch der Gau passiert.
Daher mein Tip bei solchen Sachen:
Alles haarklein zu jedem Modell dokumentieren und aufschreiben. Danach in einem Ordner ablegen, und immer schön aktualisieren. Dann hat man im Normalfall keine Probleme mehr damit!
im Grunde hast Du ja Recht, nur ist der Programmierer einer Firmware dazu verpflichtet die Software so zu gestalten, dass eben solche Systemüberlastenden Möglichkeiten (auch durch evtl. Falscheingaben) gar nicht erst genutzt werden können!
1. Alle Features die in einer Anleitung drinstehen müssen funktionieren
2. Alle Eingaben die in einer Software gemacht wurden, die nicht dem Handbuch entsprechen dürfen keine Ausfälle verursachen!
In diesem Fall würde ich sagen, dass die Programmierung nicht vollständig durchdacht und getestet ist.
Ich weiss allerdings auch, dass Software (auch im versicherungstechn. Sinn) als nicht zu 100% testbar gilt.
Ich sehe bei den heutigen Sendern viel eher das Problem darin, dass der Jenige der das Modell programmiert und eingestellt hat meistens durch seine eigenen Programmierungen nicht mehr durchsteigt, dann irgendwelche Verknüpfungen nicht richtig beseitigt, und bei irgendwelchen Zeitabläufen oder in einem anderen Flugzustand dann halt dadurch der Gau passiert.
Daher mein Tip bei solchen Sachen:
Alles haarklein zu jedem Modell dokumentieren und aufschreiben. Danach in einem Ordner ablegen, und immer schön aktualisieren. Dann hat man im Normalfall keine Probleme mehr damit!
Steffen
User
Man kann einen Prozessor nicht 'überlasten', schon gar nicht in einem Firmwarebasierten System, in dem vorgegebene Abläufe mit Parametern gespeist werden. Man injiziert schliesslich keinen Code durch die Parametereinstellungen.
Was hast Du denn gemacht, das zu einem solchen Effekt führt? Sowas ist nämlich entweder ein Bug in der Firmware oder eine fehlerhafte Programmierung. Gib doch mal die genaue Programmierung, die Du hattest, dann kann man nachvollziehen, was da passiert.
Was hast Du denn gemacht, das zu einem solchen Effekt führt? Sowas ist nämlich entweder ein Bug in der Firmware oder eine fehlerhafte Programmierung. Gib doch mal die genaue Programmierung, die Du hattest, dann kann man nachvollziehen, was da passiert.
Würde mich auch einmal interessieren, Rudolf!
Holofernes
User
Wie äußert sich das bzw. woran kann ich das erkennen oder was passiert denn dann?
matteusel
User
Hallo Rudy,
in einem sauber designten Hardwaresystem kann man softwareseitig einen Prozessor nicht überlasten. Mehr wie Rechenoperationen in einem bestimmten Takt ausführen kann dieser nämlich nicht. Wenn hier ein System abschmiert dann liegt dies auf der Softwareseite, sprich die Software ist fehlerhaft. Wenn es sich hierbei um einen reproduzierbaren Fehler handelt sollte man diesen dokumentieren und das Problem an Graupner weiterleiten.
Matthias
[ 15. Dezember 2002, 19:37: Beitrag editiert von: matteusel ]
in einem sauber designten Hardwaresystem kann man softwareseitig einen Prozessor nicht überlasten. Mehr wie Rechenoperationen in einem bestimmten Takt ausführen kann dieser nämlich nicht. Wenn hier ein System abschmiert dann liegt dies auf der Softwareseite, sprich die Software ist fehlerhaft. Wenn es sich hierbei um einen reproduzierbaren Fehler handelt sollte man diesen dokumentieren und das Problem an Graupner weiterleiten.
Matthias
[ 15. Dezember 2002, 19:37: Beitrag editiert von: matteusel ]
Hallo Jungs,
dass man Multitasking-Steuerungssoftware durch Parametereingabe ausserhalb des geplanten Wertebereichs zum Abstürzen bringen kann, ist doch wohl eine Tatsache. Sowas erlebe ich täglich (Zulieferung von Funktionen durch andere Firmen). Ursache ist, wie k_wimmer sagt, ein nicht ausreichendes Begrenzen der Eingabewerte bzw. Parameter auf vorgesehenen Betriebsfälle.
Beliebt sind als Quelle Tabellenzugriffe, die dann über ihren Bereich hinaus irgendwohin greifen und Schwachsinnswerte liefern und besonders wirkungsvoll sind Sprungtabellen, die an der adressierten Stelle keinen Eintrag haben und den zufällig dort befindlichen Speicherwert als anzuspringende Adresse werten.
Wenn nun das besagte System kein Echtzeitbetriebssystem mit Laufzeitüberwachung für einzelne Tasks enthält, erfolgt vermutlich kein Neustart und das Programm läuft ohne sinnvolle Reaktion in einer Endlosschleife. Klar, der Prozessor wird nicht überlastet, aber es passiert bis zum Neustart nichts sinnvolles mehr.
Das passiert leider auch heute noch, in Zeiten von Hochsprachenanwendung und Realtime-Betriebssystemen auf Microcontrollern.
Also nur "bestimmungsgemässe" Anwendung lt. Handbuch, ansonsten steigt das Risiko. Die Hersteller wirds erfahrungsgemäss kaum kümmern...
Übrigens sind meine Aussagen nicht auf einen speziellen Fall eines Fernsteuersenders gemünzt, sondern auf meine Erfahrungen in der fröhlichen Welt der Microcontroller-Steuerungstechnik bezogen.
Gruss
Axel
dass man Multitasking-Steuerungssoftware durch Parametereingabe ausserhalb des geplanten Wertebereichs zum Abstürzen bringen kann, ist doch wohl eine Tatsache. Sowas erlebe ich täglich (Zulieferung von Funktionen durch andere Firmen). Ursache ist, wie k_wimmer sagt, ein nicht ausreichendes Begrenzen der Eingabewerte bzw. Parameter auf vorgesehenen Betriebsfälle.
Beliebt sind als Quelle Tabellenzugriffe, die dann über ihren Bereich hinaus irgendwohin greifen und Schwachsinnswerte liefern und besonders wirkungsvoll sind Sprungtabellen, die an der adressierten Stelle keinen Eintrag haben und den zufällig dort befindlichen Speicherwert als anzuspringende Adresse werten.
Wenn nun das besagte System kein Echtzeitbetriebssystem mit Laufzeitüberwachung für einzelne Tasks enthält, erfolgt vermutlich kein Neustart und das Programm läuft ohne sinnvolle Reaktion in einer Endlosschleife. Klar, der Prozessor wird nicht überlastet, aber es passiert bis zum Neustart nichts sinnvolles mehr.
Das passiert leider auch heute noch, in Zeiten von Hochsprachenanwendung und Realtime-Betriebssystemen auf Microcontrollern.
Also nur "bestimmungsgemässe" Anwendung lt. Handbuch, ansonsten steigt das Risiko. Die Hersteller wirds erfahrungsgemäss kaum kümmern...
Übrigens sind meine Aussagen nicht auf einen speziellen Fall eines Fernsteuersenders gemünzt, sondern auf meine Erfahrungen in der fröhlichen Welt der Microcontroller-Steuerungstechnik bezogen.
Gruss
Axel
Schade Rudolf! So etwas reproduzierbar wäre sicherlich hoch interessant gewesen. Ein ähnliches Phänomen ist mir vor ca. 25 Jahren bei einer Becker-Anlage begegnet.
[ 15. Dezember 2002, 21:08: Beitrag editiert von: Arno Wetzel ]
Hey, du darfst nicht so viel bei RC-Heli posten, dann klappt´s auch mit der Flat-Rate!
[ 15. Dezember 2002, 21:08: Beitrag editiert von: Arno Wetzel ]
Steffen
User
Hi Rudolf,
Vesuche es doch mal bitte in einer kurzen Aufzählung, der Art 'Geberschalter 1 auf Kanal x mit nn%, Mischer 1 von Kanal n auf Kanal m'.
Es wäre allen geholfen, wenn man weiss, was das Problem ist, ein pauschales 'Vorsicht vor komplexen Programmierungen' nutzt nicht, ich habe mir schliesslich eine mc24 gekauft, weil ich komplizierte Programmierungen machen wollte.
Ciao, Steffen
Ich versteh kein Wort.
Vesuche es doch mal bitte in einer kurzen Aufzählung, der Art 'Geberschalter 1 auf Kanal x mit nn%, Mischer 1 von Kanal n auf Kanal m'.
Es wäre allen geholfen, wenn man weiss, was das Problem ist, ein pauschales 'Vorsicht vor komplexen Programmierungen' nutzt nicht, ich habe mir schliesslich eine mc24 gekauft, weil ich komplizierte Programmierungen machen wollte.
Ciao, Steffen
Hi Steffen,
keine Angst wegen der MC24, der Warnhinweis galt ausdrücklich für die MC22, die eine ganz andere interne Verarbeitung hat als die MC24.
hi ALLE,
Ich habe bei stillgelegtem HF-Teil mehrere Stunden probiert, das erwähnte Problem wieder herbeizuführen.
ES IST MIR NICHT MEHR GELUNGEN und es war wohl eines der singulären Ereignisse, mit denen wir in der Fernsteuertechnik immer wieder konfrontiert werden. So wie mit den diversen "Out of memory" und sonstigen mystischen Ereignissen.
Tatsache ist, es kann es geben, wird aber vielleicht nie wieder auftreten. Bei "Normalprogrammierungen" auf keinem Fall.
Wobei angenommen werden kann, dass es sich auch um ein Einzelproblem meines Senders handeln könnte.
Hi Arno,
das zu reproduzieren wäre schon SEHR interessant gewesen, wohl,wohl. Schade, dass es nicht mehr gelang. Andererseits bin ich sehr froh darüber, denn den Servobalken plötzlich SPORADISCH auf 150%, in dem Fall techn. unmöglich, zu sehen, war für mich schon ein kleiner Schock. Auf solche Schocks bin ich im Vertrauen auf die Senderqualität schon ÜBERHAUPT nicht scharf!
[ 18. Dezember 2002, 10:16: Beitrag editiert von: Rudy Fiala ]
keine Angst wegen der MC24, der Warnhinweis galt ausdrücklich für die MC22, die eine ganz andere interne Verarbeitung hat als die MC24.
hi ALLE,
Ich habe bei stillgelegtem HF-Teil mehrere Stunden probiert, das erwähnte Problem wieder herbeizuführen.
ES IST MIR NICHT MEHR GELUNGEN und es war wohl eines der singulären Ereignisse, mit denen wir in der Fernsteuertechnik immer wieder konfrontiert werden. So wie mit den diversen "Out of memory" und sonstigen mystischen Ereignissen.
Tatsache ist, es kann es geben, wird aber vielleicht nie wieder auftreten. Bei "Normalprogrammierungen" auf keinem Fall.
Wobei angenommen werden kann, dass es sich auch um ein Einzelproblem meines Senders handeln könnte.
Hi Arno,
das zu reproduzieren wäre schon SEHR interessant gewesen, wohl,wohl. Schade, dass es nicht mehr gelang. Andererseits bin ich sehr froh darüber, denn den Servobalken plötzlich SPORADISCH auf 150%, in dem Fall techn. unmöglich, zu sehen, war für mich schon ein kleiner Schock. Auf solche Schocks bin ich im Vertrauen auf die Senderqualität schon ÜBERHAUPT nicht scharf!
[ 18. Dezember 2002, 10:16: Beitrag editiert von: Rudy Fiala ]
Steffen
User
Inwiefern soll die anders sein? Es ist nahezu die gleiche Hardware, da wäre JR ziemlich unvernünftig, da eine komplett andere Firmwasre drinzuhaben.
Schilder doch trotzdem mal, was Du in etwa gemacht hattest. Auch wenn Du es nicht reproduziert bekommst, interessiert mich auch in etwa die Form, die zu sowas führen kann.
Ciao, Steffen
Hi Steffen,
Die MC22 hat mit der MC24 elektronisch nur mehr sehr wenig zu tun.
Die MC 24 ist eine verbesserte MC20
-SPCM
-2048 Schritt PPM
-Keine Frametime-abhängigen Mischer-Zeitverluste.
MC22: siehe Graupnerwerbung
Rest unwesentlich, bereinigt.
Fröhliche Weihnachten, R.
[ 19. Dezember 2002, 10:17: Beitrag editiert von: Rudy Fiala ]
Die MC22 hat mit der MC24 elektronisch nur mehr sehr wenig zu tun.
Die MC 24 ist eine verbesserte MC20
-SPCM
-2048 Schritt PPM
-Keine Frametime-abhängigen Mischer-Zeitverluste.
MC22: siehe Graupnerwerbung
Rest unwesentlich, bereinigt.
Fröhliche Weihnachten, R.
[ 19. Dezember 2002, 10:17: Beitrag editiert von: Rudy Fiala ]
Steffen
User
Nein, kann ich nicht. Wir haben drei unterschiedliche Lösungen gehabt, Deine hat irgendeinen Effekt gehabt, den es zu untersuchen gilt, aber Deine Beschreibung Deiner Programmierung kann ich nicht nachvollziehen. Mich würde interessieren, was Du da programmiert hast, damit man sich ein Bild davon machen kann.
Sehe ich nicht so. Der Prozessorkern ist der gleiche (und damit das gesamte A/D System), lediglich das Display ist anders und die Tasteingänge sind anders.
Was soll denn sonst noch der Unterschied sein? Ich kann in Deinen Artikeln keinerlei Informationen dazu finden. Da gehst Du lediglich in direktem Vergleich auf mc20 zu 22 ein.
Es wäre schön, wenn Du mal eine genaue Information dazu geben könntest, dann hätten alle was davon.
Ciao, Steffen
Moin,
was soll die Diskussion?
Entweder, ich bringe die Senderprogrammierung durcheinander, indem ich 1. 2. 3. verschiedenes nacheinander durchführe, und das Ding macht 'tilt'. Dann bitte 1. und 2. und 3. beschreiben.
Oder ich kann das nicht, weil ich das einmal eingetretene Phänomen nicht reproduzierern kann. Dann halte ich besser meinen Mund.
Rudolf, so geht das nicht. Ich und sehr viele andere respektieren Dich als Fachmann, und es ist auch verständlich (bei dem Dir zuzuschreibenden credo 'Safety first') wenn Du ein latentes Sicherheitsproblem zunächst auch ohne Verifikation öffentlich machst.
Nur, recht bald danach musst Du Ross und Reiter nennen. Wenn sich dieses Problem nicht reproduzieren lässt, besteht es nicht. Fakt. Besser ist es, eine Entwarnung zu geben, als so etwas wie eine 'Prozessorüberlastung' zu postulieren. Dazu sind diese Anlagen, um die allerhöflichste Foremulierung zu gebrauchen, gar nicht fähig.
Grüße, Ulrich Horn
was soll die Diskussion?
Entweder, ich bringe die Senderprogrammierung durcheinander, indem ich 1. 2. 3. verschiedenes nacheinander durchführe, und das Ding macht 'tilt'. Dann bitte 1. und 2. und 3. beschreiben.
Oder ich kann das nicht, weil ich das einmal eingetretene Phänomen nicht reproduzierern kann. Dann halte ich besser meinen Mund.
Rudolf, so geht das nicht. Ich und sehr viele andere respektieren Dich als Fachmann, und es ist auch verständlich (bei dem Dir zuzuschreibenden credo 'Safety first') wenn Du ein latentes Sicherheitsproblem zunächst auch ohne Verifikation öffentlich machst.
Nur, recht bald danach musst Du Ross und Reiter nennen. Wenn sich dieses Problem nicht reproduzieren lässt, besteht es nicht. Fakt. Besser ist es, eine Entwarnung zu geben, als so etwas wie eine 'Prozessorüberlastung' zu postulieren. Dazu sind diese Anlagen, um die allerhöflichste Foremulierung zu gebrauchen, gar nicht fähig.
Grüße, Ulrich Horn
Hi Alle,
der thread hatte, wie schon knapp vorher ausdrücklich erwähnt, ein auch nicht in stundenlangen Versuchen mehr reproduzierbares Geschehen zur Basis. Möglicherweise eine "Privatsache" MEINES Senders.
Ich habe somit den Threadnahmen auf "ENTwarnung...." geändert, da die Sicherheitsbedenken nicht mehr verifizierbar waren und nicht zur allgemeinen Verunsicherung führen sollen.
Da der Sender völlig flugentsprechende Programmiermöglichkeiten enthält, gibt es für 1000ende von Piloten ohnedies keinen Grund zu "künstlerischen" Programmierungen aus seltenen Gründen.
Ich entschuldige mich für die ausgelösten Reaktionen, die von mir in dieser Form nicht vorhersehbar waren.
An der Sache an sich - MEINEN Sender betreffend - ändert das allerdings nichts.
Dass ich künftig bei Hilfeversuchen aber anderen Fachleuten den Vortritt lassen werde, ist wohl auch klar. Erspart mir einen Menge Flatratekosten durch überziehen der Pauschale.
Der ganze Motorregelungsthread war ohnedies für alle Mitarbeitenden aus leicht erkennbaren Gründen kaum von Wonne-Anfällen geprägt, leider sogar sinnlos. Sinnlos vergeudete Zeit. Na ja, für mich NICHT, da ich schockartig erlebte, dass es Grenzen, leider nicht reproduzierbar, geben kann. Eben so wie die noch immer ungelösten Memory-Meldungphänomene der MC24, die ich auch nur aus den Foren kenne und persönlich nie erlebt habe.
Fröhliche Weihnachten und eine erfolgreiche, absturzfreie Saison 2003!
[ 19. Dezember 2002, 10:48: Beitrag editiert von: Rudy Fiala ]
der thread hatte, wie schon knapp vorher ausdrücklich erwähnt, ein auch nicht in stundenlangen Versuchen mehr reproduzierbares Geschehen zur Basis. Möglicherweise eine "Privatsache" MEINES Senders.
Ich habe somit den Threadnahmen auf "ENTwarnung...." geändert, da die Sicherheitsbedenken nicht mehr verifizierbar waren und nicht zur allgemeinen Verunsicherung führen sollen.
Da der Sender völlig flugentsprechende Programmiermöglichkeiten enthält, gibt es für 1000ende von Piloten ohnedies keinen Grund zu "künstlerischen" Programmierungen aus seltenen Gründen.
Ich entschuldige mich für die ausgelösten Reaktionen, die von mir in dieser Form nicht vorhersehbar waren.
An der Sache an sich - MEINEN Sender betreffend - ändert das allerdings nichts.
Dass ich künftig bei Hilfeversuchen aber anderen Fachleuten den Vortritt lassen werde, ist wohl auch klar. Erspart mir einen Menge Flatratekosten durch überziehen der Pauschale.
Der ganze Motorregelungsthread war ohnedies für alle Mitarbeitenden aus leicht erkennbaren Gründen kaum von Wonne-Anfällen geprägt, leider sogar sinnlos. Sinnlos vergeudete Zeit. Na ja, für mich NICHT, da ich schockartig erlebte, dass es Grenzen, leider nicht reproduzierbar, geben kann. Eben so wie die noch immer ungelösten Memory-Meldungphänomene der MC24, die ich auch nur aus den Foren kenne und persönlich nie erlebt habe.
Fröhliche Weihnachten und eine erfolgreiche, absturzfreie Saison 2003!
[ 19. Dezember 2002, 10:48: Beitrag editiert von: Rudy Fiala ]
Steffen
User
Rudy, wo kommt die Information her, dass die 24 keine 2048 Schritte PPM hat? SPCM hat die 24 auch.
Frametime-Verluste durch Mischer? Erklär das bitte mal genauer, was Du damit meinst (mit Vergleich MC24 zu MC22 (MC20 interessiert dabei nicht)
Dazu nochmal die Bitte: sage doch, was Du in etwa gemacht hast. Auch wenn es nicht reproduzierbar ist.
Aber bitte in klaren Aufzählungen, nicht in einem zusammengefassten Satz.
Also zB:
1 Geberschalter auf K1 bei 10%
e Geberschalter auf K1 bei 20%
G1 löst K7 aus mit Zeitverzögerung
der mischt auf K1
Oder so in der Art.
Auch wenn Du es selbst nicht reproduziert bekommst, ist die grundsätzliche Anordnung für mich von Interesse. Du kannst es mir ja auch gerne per EMail schicken. Aber bitte mache es einfach mal, ich bin sehr neugierig.
Ciao, Steffen
Frametime-Verluste durch Mischer? Erklär das bitte mal genauer, was Du damit meinst (mit Vergleich MC24 zu MC22 (MC20 interessiert dabei nicht)
Dazu nochmal die Bitte: sage doch, was Du in etwa gemacht hast. Auch wenn es nicht reproduzierbar ist.
Aber bitte in klaren Aufzählungen, nicht in einem zusammengefassten Satz.
Also zB:
1 Geberschalter auf K1 bei 10%
e Geberschalter auf K1 bei 20%
G1 löst K7 aus mit Zeitverzögerung
der mischt auf K1
Oder so in der Art.
Auch wenn Du es selbst nicht reproduziert bekommst, ist die grundsätzliche Anordnung für mich von Interesse. Du kannst es mir ja auch gerne per EMail schicken. Aber bitte mache es einfach mal, ich bin sehr neugierig.
Ciao, Steffen
@rudy: ich finde das nachtraegliche aendern (also so nach einer woche bei zig bereits erfolgten folge-postings) schrecklich. man begreift nichts mehr, worum es ging. kostet mich zusatzzeit, der fred beim lesen. muss das sein? bitte unterlassen. die entwarnung haettest du doch einfach per posting machen koennen. fertig. war halt eine art irrtum, was solls.
also fuer meinen geschmack war die sache selbst durchaus ok, aber das wie nicht so toll.
gruss rainer
also fuer meinen geschmack war die sache selbst durchaus ok, aber das wie nicht so toll.
gruss rainer
WIEDERHOLUNG, Originaltext
erstellt am: 18. Dezember 2002 20:16
--------------------------------------------------------------------------------
Hi Steffen,
Die MC22 hat mit der MC24 elektronisch nur mehr sehr wenig zu tun.
Die MC 24 ist eine verbesserte MC20
-SPCM
-2048 Schritt PPM
-Keine Frametime-abhängigen Mischer-Zeitverluste.
MC22: siehe Graupnerwerbung
ENDE ORIGINALTEXT
Deine Frage kurz oberhalb mit der inkludierten Feststellung, ich hätte behauptet die mc24 hätte keine 2048 PPM-Schritte ist damit beantwortet. irgendwie überraschend, dass du sie gestellt hast.
Hi Leinel (und Steffen, teilweise),
kann mir schon vorstellen, dass Du frustriert
bist. Aber ich kann mich auf die Details der stundenlangen Herumprogrammiererei gar nicht mehr erinnern.Als es passiert war, nämlich die zufällig auf 150% springende Servoanzeige, dachte ich mir "aha, so gehts nicht; weg damit, resetten" Und damit wars weg. Hätte auf einem anderen Speicherplatz neu beginnen sollen, dann wär es dokumentiert gewesen.
Das Löschen der Beiträge hat schon einen Sinn: Die, dies gelesen haben, brauchen es nicht mehr.
Und die, die es noch nicht kennen, BRAUCHEN ES GAR NICHT MEHR KENNENZULERNEN. Und das können sie somit gar nicht mehr.
Sorry, Gruß, Rudy
[ 19. Dezember 2002, 16:37: Beitrag editiert von: Rudy Fiala ]
erstellt am: 18. Dezember 2002 20:16
--------------------------------------------------------------------------------
Hi Steffen,
Die MC22 hat mit der MC24 elektronisch nur mehr sehr wenig zu tun.
Die MC 24 ist eine verbesserte MC20
-SPCM
-2048 Schritt PPM
-Keine Frametime-abhängigen Mischer-Zeitverluste.
MC22: siehe Graupnerwerbung
ENDE ORIGINALTEXT
Deine Frage kurz oberhalb mit der inkludierten Feststellung, ich hätte behauptet die mc24 hätte keine 2048 PPM-Schritte ist damit beantwortet. irgendwie überraschend, dass du sie gestellt hast.
Hi Leinel (und Steffen, teilweise),
kann mir schon vorstellen, dass Du frustriert
bist. Aber ich kann mich auf die Details der stundenlangen Herumprogrammiererei gar nicht mehr erinnern.Als es passiert war, nämlich die zufällig auf 150% springende Servoanzeige, dachte ich mir "aha, so gehts nicht; weg damit, resetten" Und damit wars weg. Hätte auf einem anderen Speicherplatz neu beginnen sollen, dann wär es dokumentiert gewesen.
Das Löschen der Beiträge hat schon einen Sinn: Die, dies gelesen haben, brauchen es nicht mehr.
Und die, die es noch nicht kennen, BRAUCHEN ES GAR NICHT MEHR KENNENZULERNEN. Und das können sie somit gar nicht mehr.
Sorry, Gruß, Rudy
[ 19. Dezember 2002, 16:37: Beitrag editiert von: Rudy Fiala ]
Ähnliche Themen
