Neee, die Wette...
 

... halte ich nicht :)

Ich meinte mit "ohne Stabiltäts- und Höhenverlust" natürlich "mit nur geringem....". 50 oder 100 ft Höhe... wie's Chris geschrieben hat. Völlig "Ohne" im strengen Sinne geht ja garnicht...

Ähhh.. was die stetigen technischen Funktionen angeht... Habt Ihr nicht wieder beide recht? Natürlich, keine (sogar n-te?) Ableitung kann in der Realität unendlich werden (recht gross natürlich schon). Unabhängig davon man kann aber doch z.B. (Regler)funktionen auch stückweise linear (oder quadratisch oder wie auch immer) approximieren (im Softwaresystem). Unstetig :)

Eine Möglichkeit der (theoretischen) Charakterisierung von Regelsystemen ist doch z.B. die Sprung-Antwortfunktion (Einheitssprung als Regelabweichung, wie antwortet der Regler).

Ich seh' schon, wir sind wieder mitten drin... :)

Viele Grüsse
Peter

Das von Dir angeführte Beispiel der linearen Reglerapproximation hat eine behebbare Unstetigkeit...... ;) kann also als stetig betrachtet werden, da beide Gerade EINEN Punkt gemeinsam haben

mathematisch: links- und rechtsseitiger Grenzwert sind gleich

Tatsächlich unstetig verlaufen z.B. Schmelzvorgänge (Temp bleibt konstant während Wärme zugeführt wird)

Hmmm... ja...
 

... bezüglich der behebbaren Unstetigkeit würd' ich Dir jetzt sooo gerne widersprechen... kann's aber natürlich nicht, ist ja ganz richtig... :motz: :)

Zur Unstetigkeit bei Schmelz- etc-Vorgängen (Phasenwechseln)... äääh... müsst' ich glatt drüber nachgrübeln, da reicht meine Munition für einen Schnellschuss aus der Hüfte im Moment :eek: nicht. Verläuft sowas wirklich im strengen Sinne unstetig?

Viele Grüsse
Peter

ja, dies ist tatsächlich so, es wird Schmelzwärme zugeführt, die gänzlich zur Änderung des Aggregatzustandes "verbraucht" wird, da bleibt nix zur Temperaturerhöhung. Erst nach vollständigem Schmelzen steigen die Gräder wieder......

Ebenso bei der Verdampfung.......

Fakt bleibt halt mal, daß technische Vorgänge real nie unstetig verlaufen, auch wenn´s manchmal fast so aussieht.......

Sehr gut sieht man dies ja am Oszi, die Flankenanstiegszeit ist auch eine Definitionsgröße in der Halbleitertechnik........

Und Hochspannungsschalter schmazen oder schlürfen, wie der Fachmann weiß :) je nach dem ob Wechsel- oder Gleichspannung, selbst ein triviale Lichtschalter schafft keinen unstetigen Abbau des Widerstandes von (nahezu) unendlich auf sehr gering (leitend) ......

Moin,

@hauptsächlich AUA348: :)

auch dir scheint wohl nicht klar zu sein, was ich eigendlich damit Bezwecken will. Du kannst es wahrscheinlich auch nicht wissen. Darum werde ich es dir nochmal erleutern:

Ich möchte mir eine FEP selbst Programmieren, weil ich einen Tieferen einblick in die Technik wagen möchte. Anscheinen darf man das nicht - Stattdessen wird einen doch empfolen, man solle es ganz schnell sein lassen, da die Bevölkerung dumm gehalten werden soll.

Ich weiß, das ist nun übertrieben - Natürlich war das von dir auch nicht so gemeint. Deine Anspielungen treffen jedoch nur zu, wenn ich mir eine Produktiv-FEP programmieren möchte. Wobei mein Projekt durchaus irgendwann mal dazu genutzt werden kann. Das möchte ich nicht abstreiten - und du kannst es nicht - Wenn wir so verweilen dürften wir ein so ziemlich im Konsens stehen.

Nun noch ein paar Worte zu einigen Anspielungen:
Es braucht nicht Experten, um etwas nachzukonstruiren. - Jediglich sollte man das Handwerk verstehen. - Experten braucht man, um solche Systeme zu entwickeln.

Ich habe nie davon gesprochen, das ich ein ganzes Flugzeug selbst bauen möchte. Jediglich die FEB. Das wäre bei einem Auto z.B. mittels den Spezifikationen des Herstellers das ABS "anzupassen".

Nun noch eine kleine Büttenrede zu dem Thema "Echtzeit". Es ist einfach Sinnfrei für eine Simulation in Echtzeit zu programmieren. Kein Computer der Welt kann in echtzeit etwas Simmulieren, da egal wie Schnell die Kiste ist, immer nur ein Befehl bzw. ein Thread pro CPU (bei Multi-CPU Betrieb) abarbieiten kann. Ein PC mit 32 CPUs ist für uns unbezahlbar - Und könnte somit 32 Threads, sprich 32 Parameter auf einmal berechnen, nicht mal die Hälfte der Basics in einer Simulation. Eine Simulation ist bloß schneller, als der Mensch reagieren kann. Darum ist es auch genau so sinnfrei ein Netzwerkprotokoll zu schreiben, was angeblich für "Echzeitstreaming" aus gelegt ist. - Auf eine Netzwerkkarte kann immer nur ein Prozess auf einmal schreiben ODER lesen. So kann also auch nur das FEP von dem du mir preist, immer nur ein Offset zur selben Zeit auslesen -> auswerten und wieder zurückschreiben, wenn nötig. TCP/IP jedoch ist schneller als der Mensch reagieren kann. An dieser Stelle zb. hat man sich unötig mehr aufwand gemacht, bloß um alles so zu programmieren, wie im Original.

Und es gibt noch viel viel mehr solcher Prozeduren die man sich unnötig schreibt.

Natürlich muss man die Hauptverknüpfungen: Speed, Flaps/Slats, Nickwinkel, Querneigung - auch wichtig noch vorhande Leistungsresourcen - verknüpfen, sonst wird es nichts - Das stimmt. Wofür es aber keine Experten mehr benötigt.

So, ich hoffe das dies nun auch mal ein paar Leuten die Augen öffnet. - Das soll nun auch keine "Bösewicht"-Mail sein. - Bloß um auch die knallharten Realisten auf den Teppich zurück kommen zu lassen.

MfG
Karsten

Sorry, Karsten, aber ich denke, da bringst Du eine Menge Dinge durcheinander......

PS: Habe Dein mail erhalten, aber damit kann ich nun wirklich nix anfangen, bzw. damit läßt sich keine FBW-Regelfunktion erstellen...

wo bringe ich was durcheinander?

Wo wir schonwieder beim Thema sind :lol: -> keiner versucht mir dann auch zu helfen, es wird nur im den kalten Brei gelabert.

Ps: Ok, vielleicht kannst du mir unter diesem Unständen auch einfach (in bezug auf die funktion) nicht helfen. Ich müsste dann auch nochmal von dir wissen, was du benötigst, inwiefern du bereit wärst selbständig Infos zusammen zu stellen etc.

Ps: In Bezug auf die Echtzeit, was ja eigendlich bei euch Realisten die größten Probleme auftauche lassen, ist nichts Falsch. Es ist "leider" so...

MfG
Karsten

Wie mir scheint tun meine Angaben zu diesem Thema im jetzigen Stadium auch nix mehr zur Sache. Aber trotzdem: Die Busse sind gar nicht darauf ausgelegt, bei Änderungen der Banklage die Pitchlage konstant zu halten! Erst wenn eine konstante Banklage eingenommen worden ist arbeitet Autotrim einigermaßen zur Zufriedenheit. Solange noch Querrudereingaben gemacht werden muss am Knüppel gezogen bzw. gedrückt werden, fast wie in einem konventionellen Flugzeug.

Was Autotrim außerdem nicht kann: Den Pitchwinkel konstant halten während die Triebwerksleistung geändert wird! Gerade die großen Triebwerke der 330er Baureihen lassen bei Powerchanges das Flugzeug so sehr pitchen, dass man die Schubsteuerung besser von Hand vornimmt, wenn man von Hand steuert. Der 320 ist da unempfindlicher. Ihn kann man ganz gut von Hand fliegen und den Schub vom Autothrustsystem regeln lassen.

Meine 2 Cent.

Happy landings!

HP

Um Missverständnissen vorzubeugen: Ich habe in diesem meinem Posting immer vorausgesetzt das Flugzeug wird von Hand gesteuert. Ist der Autopilot am Werk, ist es ja wenig sinnvoll von Flugverhalten zu sprechen.

Das war eine interessante Info, wird wieder den Einen oder Anderen desillusionieren...... :)

Das beste FBW Flugzeug, das ich je am PC geflogen habe, war die Su-27 Flanker. Sie hat zwar bei weitem nicht die Flightenvelope Protections wie die Busse sondern eher so etwas wie eine Stabilisierungshilfe, aber genau das machte sie so angenehm zu fliegen. Vielleicht sollte man jenen Programmierern mal über die Schulter schauen? Der eine oder andere Ansatz müßte doch brauchbar sein, denke ich mir als Nicht-Programmierer.

HP