Frank Ranis
User
Hallo Thomas,
danke für dein Lob.
Ja , das Aero-Programme schreiben ist wirklich eine Lebensaufgabe und alles ohne Abi und Studium .
>>>>
Es würde mich aber mal interessieren auf welcher Art Rückmeldungen Du überhaupt entscheidest ob Deine Änderungen nun erfolgreich (bzw. richtig) waren oder nicht.
<<<<
Also als erstes steht ja mal das Programm da und die Kollegen arbeiten damit.
Es werden dann Modelle gebaut und wenn fertig wird die Theorie mit der Praxis verglichen , auf dem Modellflugplatzt.
Wenn es dabei zu Differenzen kommt , wird vielleicht hier im Forum ein Beitrag aufgemacht und eine wilde Diskussion nimmt seinen Anfang.
Ursachenforschung , Erfahrung und Vorschläge zu Verbesserung , Vermutungen .
Das ist an sich ja auch schon eine Rückmeldung und aus all den Beiträgen kann dann eventuell eine Idee entstehen , die man Testweise programmiert.
Solche Testversionen werden natürlich nicht gleich veröffentlicht , sondern an Kollegen verteilt , die sehr aktiv Modellbau betreiben und Ahnung haben.
Jetzt geht das warten auf Rückmeldungen los .
Dabei gibt es beide Arten von Rückmeldungen , wie Du geschrieben hast:
1) Die Gefühlsmäßigen (sieht irgendwie besser aus, oder kommt scheinbar besser hin) .
2) Aber auch die Profi-Lösung , soweit das im Modellflug , ohne Windkanal möglich ist (z.B. Datenlogger mit Staurohr) .
Schön wäre dann noch , wenn ich davon auch Wind bekäme , ich bin nicht jeden Tag im RC-Network unterwegs , und stoße dann eher durch Zufall auf das Thema.
Eine kurze E-Mail-Info wäre da schon gut (Hallo Frank schau da mal rein) .
Das Beispiel mit der FLZ_Vortex-XFoil-Anbindung für die bessere Profil-Nickmomenten-Erfassung wäre so eine wünschenswerter Fall gewesen.
Hier ging es ja um die Schwerpunktlagen (speziell bei Nurflügeln) , weil die Programme da etwas daneben lagen (meist zu weit vorne) .
Also Ursache wurde dann das Profil-Nickmoment ausgemacht , in den Programmen wird das Reibungsfreie Nickmoment genommen (Thin-Airfoil-Theorie) und XFoil liefert eine bessere Aussage mit Reibungseinfluss bei verschiedenen Re-Zahlen.
Da hat es aber fast komplett an den Rückmeldungen gefehlt , so das ich es dann irgendwann verworfen habe.
Im nachhinein habe ich aber (durch Hinweise hier im RC-Network) mitbekommen , das diese Testversion erfolgreich eingesetzt wird und die Schwerpunktlagen sehr gut berechnet.
Schitt , Schitt :
1) Die Versionen der letzte 10 Jahre haben diese Funktion nicht mehr drin , habe dann einfach mit der Km-langen Wunschliste weitergemacht.
2) Dann habe das FLZ_Vortex auch zwischendurch auf meine neue Entwicklungsumgebung (Lazarus) portiert , dabei gab es auch so manche Änderung.
3) Und viele andere Änderungen gemacht , so das das damalige Konzept (mit dem XFoil) leider nicht mehr einfach wieder eingebaut werden kann.
Das müsste man nun fast komplett neu angehen , wieder mit Vorab-Testversionen , boa.
Ein anderes Beispiel , wo es erheblich besser gelaufen ist.
Thema: Einfluss eines Rumpfes auf die Auftriebsverteilung und Schwerpunkt .
Beim Nuri-Treffen 2018 (Am Abend in der Kneipe) hatte Florian Rösch einen Wunsch für das FLZ-Vortex geäußert.
Rümpfe kann man im FLZ_Vortex ja nicht richtig gut simulieren , das ran gefrickel mit zusätzlichen Flächen oder Einbau von Zwischensegmenten hat nicht wirklich gut funktioniert.
Er wollte eine Funktion , wo man an bestimmten Stellen des Flügels (z.B. am Flügel-Rumpfübergang) den Auftrieb künstlich verändern kann .
Irgendwie per Hand , ohne einen Wissenschaftlichen Hintergrund .
Da habe ich dann überlegt und mich gefragt , wie man so etwas einfach und vor allen wo im Programmcode einbauen könnte.
Nach dem Essen kam mir dann eine Idee , super einfach und recht schnell zu programmieren , ohne die eigentlichen Vortex-Lattice-Routinen zu ändern.
Das Vortex-Lattice basiert ja auf einer Panelgeometrie mit vielen kleinen Panels , einem tragenden Wirbel auf jeder Panel-t/4-Linie , verbindende Wirbel an den Panelrändern (links und rechts).
Und SUPERWICHTIG , einem Aufpunkt (Kontrollpunkt) am 3/4-Punkt eines jeden Panels .
Dieser Aufpunkt an der richtigen Stelle sorgt dann dafür , das die Thin-Airfoil-Theorie funktioniert und vernünftige Werte liefert.
Ich hatte einige Zeit zuvor mal mit der Aufpunkt-Position herumgespielt und nach vorne oder hinten verschoben.
Ergebnis , bei gleichem Anstellwinkel ergeben sich durch verschieben unterschiedliche Auftriebe .
Genau die Funktion , die Florian braucht , einfach das Vortex-Lattice-Verfahren passig biegen .
Ich habe dann im Programm eine Eingabemöglichkeit geschaffen , um an bestimmten Segmenten (z.B. da wo es eine Flügel-Rumpfüberlappung gibt) alle Panelaufpunkte zu verschieben.
Die Grundlage für Florian war nun geschaffen.
War halt nur noch rauszufinden , welche Aufpunktposition vernünftige Werte liefert.
Er hat dann durch Messflüge (Datenlogger mit Staurohr) , Rückrechnungen , Vergleiche , eine neue Position für den Aufpunkt an den Überlappungsstellen gefunden.
Diese lag an den betroffenen Stellen bei 50% der Paneltiefe , dadurch ergibt sich dann ein Auftriebseinbruch an der Position des Rumpfes.
Wenn man die Aufpunktposition noch weiter nach vorne legt , z.B. sehr nahe an die t/4-Linie (25,1% z.B.) , kann man den Auftriebs bis nahe 0 herunterschieben.
Eventuell mal interessant für Störklappen (Schempp-Hirth), müsste mal jemand am realen Modell ausprobieren und mit den Rechnungen vergleichen.
Direkt 25% darf man aber nicht eingeben , dann ergeben sich unendlich große induzierte Werte am Aufpunkt und das Prog stürzt ab.
Diese Funktion wurde mittlerweile auch bei Schwanzfliegern erfolgreich getestet.
Ein Kollege hat z.B. seine Lockheed P-38 damit gerechnet.
Diese hat ja zwei Heckausleger und einen zentralen Rumpf , also 3 Rumpf-Flügel-Überlappungen , wo man die neue Funktion benutzen kann.
Es wurde dann im FLZ_Vortex nur der Hauptflügel und das HLW gezeichnet und an allen 3 Stellen , wo Rumpf und Ausleger den Hauptflügel kreuzen die Panelposition auf 50% gesetzt.
Dadurch ergeben sich dann am Hauptflügel drei Auftriebseinbrüche .
Das Modell wurde gebaut und alles passte auf Anhieb , wie berechnet.
Seit dem ist die neue Funktion im FLZ_Vortex verfügbar , die ganze Aktion hat eine paar Wochen gedauert mit Rückmeldungen.
Gruß
Frank
danke für dein Lob.
Ja , das Aero-Programme schreiben ist wirklich eine Lebensaufgabe und alles ohne Abi und Studium .
>>>>
Es würde mich aber mal interessieren auf welcher Art Rückmeldungen Du überhaupt entscheidest ob Deine Änderungen nun erfolgreich (bzw. richtig) waren oder nicht.
<<<<
Also als erstes steht ja mal das Programm da und die Kollegen arbeiten damit.
Es werden dann Modelle gebaut und wenn fertig wird die Theorie mit der Praxis verglichen , auf dem Modellflugplatzt.
Wenn es dabei zu Differenzen kommt , wird vielleicht hier im Forum ein Beitrag aufgemacht und eine wilde Diskussion nimmt seinen Anfang.
Ursachenforschung , Erfahrung und Vorschläge zu Verbesserung , Vermutungen .
Das ist an sich ja auch schon eine Rückmeldung und aus all den Beiträgen kann dann eventuell eine Idee entstehen , die man Testweise programmiert.
Solche Testversionen werden natürlich nicht gleich veröffentlicht , sondern an Kollegen verteilt , die sehr aktiv Modellbau betreiben und Ahnung haben.
Jetzt geht das warten auf Rückmeldungen los .
Dabei gibt es beide Arten von Rückmeldungen , wie Du geschrieben hast:
1) Die Gefühlsmäßigen (sieht irgendwie besser aus, oder kommt scheinbar besser hin) .
2) Aber auch die Profi-Lösung , soweit das im Modellflug , ohne Windkanal möglich ist (z.B. Datenlogger mit Staurohr) .
Schön wäre dann noch , wenn ich davon auch Wind bekäme , ich bin nicht jeden Tag im RC-Network unterwegs , und stoße dann eher durch Zufall auf das Thema.
Eine kurze E-Mail-Info wäre da schon gut (Hallo Frank schau da mal rein) .
Das Beispiel mit der FLZ_Vortex-XFoil-Anbindung für die bessere Profil-Nickmomenten-Erfassung wäre so eine wünschenswerter Fall gewesen.
Hier ging es ja um die Schwerpunktlagen (speziell bei Nurflügeln) , weil die Programme da etwas daneben lagen (meist zu weit vorne) .
Also Ursache wurde dann das Profil-Nickmoment ausgemacht , in den Programmen wird das Reibungsfreie Nickmoment genommen (Thin-Airfoil-Theorie) und XFoil liefert eine bessere Aussage mit Reibungseinfluss bei verschiedenen Re-Zahlen.
Da hat es aber fast komplett an den Rückmeldungen gefehlt , so das ich es dann irgendwann verworfen habe.
Im nachhinein habe ich aber (durch Hinweise hier im RC-Network) mitbekommen , das diese Testversion erfolgreich eingesetzt wird und die Schwerpunktlagen sehr gut berechnet.
Schitt , Schitt :
1) Die Versionen der letzte 10 Jahre haben diese Funktion nicht mehr drin , habe dann einfach mit der Km-langen Wunschliste weitergemacht.
2) Dann habe das FLZ_Vortex auch zwischendurch auf meine neue Entwicklungsumgebung (Lazarus) portiert , dabei gab es auch so manche Änderung.
3) Und viele andere Änderungen gemacht , so das das damalige Konzept (mit dem XFoil) leider nicht mehr einfach wieder eingebaut werden kann.
Das müsste man nun fast komplett neu angehen , wieder mit Vorab-Testversionen , boa.
Ein anderes Beispiel , wo es erheblich besser gelaufen ist.
Thema: Einfluss eines Rumpfes auf die Auftriebsverteilung und Schwerpunkt .
Beim Nuri-Treffen 2018 (Am Abend in der Kneipe) hatte Florian Rösch einen Wunsch für das FLZ-Vortex geäußert.
Rümpfe kann man im FLZ_Vortex ja nicht richtig gut simulieren , das ran gefrickel mit zusätzlichen Flächen oder Einbau von Zwischensegmenten hat nicht wirklich gut funktioniert.
Er wollte eine Funktion , wo man an bestimmten Stellen des Flügels (z.B. am Flügel-Rumpfübergang) den Auftrieb künstlich verändern kann .
Irgendwie per Hand , ohne einen Wissenschaftlichen Hintergrund .
Da habe ich dann überlegt und mich gefragt , wie man so etwas einfach und vor allen wo im Programmcode einbauen könnte.
Nach dem Essen kam mir dann eine Idee , super einfach und recht schnell zu programmieren , ohne die eigentlichen Vortex-Lattice-Routinen zu ändern.
Das Vortex-Lattice basiert ja auf einer Panelgeometrie mit vielen kleinen Panels , einem tragenden Wirbel auf jeder Panel-t/4-Linie , verbindende Wirbel an den Panelrändern (links und rechts).
Und SUPERWICHTIG , einem Aufpunkt (Kontrollpunkt) am 3/4-Punkt eines jeden Panels .
Dieser Aufpunkt an der richtigen Stelle sorgt dann dafür , das die Thin-Airfoil-Theorie funktioniert und vernünftige Werte liefert.
Ich hatte einige Zeit zuvor mal mit der Aufpunkt-Position herumgespielt und nach vorne oder hinten verschoben.
Ergebnis , bei gleichem Anstellwinkel ergeben sich durch verschieben unterschiedliche Auftriebe .
Genau die Funktion , die Florian braucht , einfach das Vortex-Lattice-Verfahren passig biegen .
Ich habe dann im Programm eine Eingabemöglichkeit geschaffen , um an bestimmten Segmenten (z.B. da wo es eine Flügel-Rumpfüberlappung gibt) alle Panelaufpunkte zu verschieben.
Die Grundlage für Florian war nun geschaffen.
War halt nur noch rauszufinden , welche Aufpunktposition vernünftige Werte liefert.
Er hat dann durch Messflüge (Datenlogger mit Staurohr) , Rückrechnungen , Vergleiche , eine neue Position für den Aufpunkt an den Überlappungsstellen gefunden.
Diese lag an den betroffenen Stellen bei 50% der Paneltiefe , dadurch ergibt sich dann ein Auftriebseinbruch an der Position des Rumpfes.
Wenn man die Aufpunktposition noch weiter nach vorne legt , z.B. sehr nahe an die t/4-Linie (25,1% z.B.) , kann man den Auftriebs bis nahe 0 herunterschieben.
Eventuell mal interessant für Störklappen (Schempp-Hirth), müsste mal jemand am realen Modell ausprobieren und mit den Rechnungen vergleichen.
Direkt 25% darf man aber nicht eingeben , dann ergeben sich unendlich große induzierte Werte am Aufpunkt und das Prog stürzt ab.
Diese Funktion wurde mittlerweile auch bei Schwanzfliegern erfolgreich getestet.
Ein Kollege hat z.B. seine Lockheed P-38 damit gerechnet.
Diese hat ja zwei Heckausleger und einen zentralen Rumpf , also 3 Rumpf-Flügel-Überlappungen , wo man die neue Funktion benutzen kann.
Es wurde dann im FLZ_Vortex nur der Hauptflügel und das HLW gezeichnet und an allen 3 Stellen , wo Rumpf und Ausleger den Hauptflügel kreuzen die Panelposition auf 50% gesetzt.
Dadurch ergeben sich dann am Hauptflügel drei Auftriebseinbrüche .
Das Modell wurde gebaut und alles passte auf Anhieb , wie berechnet.
Seit dem ist die neue Funktion im FLZ_Vortex verfügbar , die ganze Aktion hat eine paar Wochen gedauert mit Rückmeldungen.
Gruß
Frank
des Flügels ging es meistens wieder.
