---

Hallo,
vor meinem ersten Beitrag erst mal ein großes Lob an das Forum. Dass es sich um meinen ersten Beitrag handelt, liegt eben daran.

Nun zu meiner Frage. Klingt eigtl. sehr simpel.
Ich möchte in einer Beziehnung den Arcussinus verwenden, etwa so:  B=2*asin(T/2*R)*(blabla...)
T ist ein fester Wert, R ebenfalls, und B möchte ich danach in ein Muster eingeben.

Nur leider gibt mir ProE keinen Wert für B aus, sondern schreibt: "Wahrscheinlicher Fehler bei Funktionsauswertung"

Bei dem ganzen handelt es sich um eine Rollenkette. Die entsprechenden Threads habe ich gelesen. Beim Mustern zweier Punkte entlang einer Leitkurve nimmt ProE als Abstand zwischen den Punkten die Länge der Kurve und nicht den direkten Abstand. Um das zu verhindern habe ich die math. Beziehung zwischen Radius der Leitkurve und der Sehne ausgerechnet.(B= usw...) Tja und der Arcsin hält mich davon ab weiterzumachen...

Hoffen jemand von euch hat einen heißen Tipp, damit es funktioniert.

[Diese Nachricht wurde von Egoduck am 16. Apr. 2008 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

wahrscheinlich ganz trivial, das Produkt anders herum schreiben, oder mit Klammern.
B=(blabla...) * 2 * asin(T/2*R)

oder:
B=T/2*R
B=asin(B)
B=2*B
B=(blabla...)*B

eigentlich genau wie in C.
Wenn Du den rechten Teil markierst, kannst Du mit = den Wert abfragen. Wenn der erwartungsgemäß ist, nächste Zeile.

------------------
"If you are not living life on the edge, you are taking up too much space". . =>MfG Khan<= 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hab rumprobiert mit Extra-Klammern und siehe da es funktioniert!
Woran es genau lag weiß ich aber immer noch nicht.

Vielen Dank!!!

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

an dem Ausdruck direkt hinter asin() . Das mag C nicht.

------------------
"If you are not living life on the edge, you are taking up too much space". . =>MfG Khan<= 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

luecke.prt.6.txt

Dieser Beitrag ermutigt mich zu einer Frage, an der ich mir derzeit die Zähne ausbeiße, da sie möglicherweise in die gleiche Richtung geht (von C habe ich keine Ahnung):

Im beiligenden Modell soll vollparametrisch die Zahnlückengeometrie eines Kegelrades am Außenrand modelliert werden. Dazu wird
a) die Geometrie der Lücke mit Hilfe der Involutfunktion ausgehend vom Grundkreis (rge) bis zum Kopfkreis (rke), 
b) und die Fortsetzung der Lücke unterhalb des Grundkreises als tangentiale Gerade an den Grundkreis definiert.

Das Ganze erfolgt in einem Zug-KE mit variablem Schnitt.
Dazu wird zuerst die Zugkurve (Skizze 1) erstellt. Diese wird unterhalb des Fußkreises um den Modul m verlängert, um beim späteren Schneiden mit dem Fußkegel definierte Randbereiche zu erhalten.

Im ZugKE wird anhand der Laufvariablen trajpar ermittelt, ob der Bereich der Tangente (1. Bereich der IF-Abfrage) oder der Evolvente (2. Bereich der IF-Abfrage) zu verwenden sind.

Skizze 2 enthält nur die Teil-, Kopf-, Fuß- und Grundkreisdurchmesser zur Ansicht.

Alles funktioniert wunderbar, solange ich bei den vorliegenden Parametern die Profilverschiebung xx=0,2 lasse. Mit Profilverschiebung xx=0 lässt sich das Modell nicht mehr regenerieren. Das ist aber technologischer Unsinn, da die Lücke auch bei xx=0 definiert ist, genau wie die Tangente. Auch fahren eine Menge Autos herum mit so einem Zahnrad.

Die Ursachenforschung ist mir eigentlich relativ egal, aber an einer praktikablen Umschiffung der Klippe wäre mir schon gelegen.

[Für weiter Interessierte/AN]
Was ich bisher vermute ist, dass die Involutfunktion inv(wi)=tan(wi)-wi*Pi/180° intern in Pro/E über einen Wurzelansatz errechnet wird. Dieser müsste dann so lauten:
inv_alfa_r= sqrt(4-m^2*zz^2*cos(beta)^2*cos(alfa)^2/((1/2*m*zz/cos(beta)-m*(1+c)-m+trajpar*(m*(ha+xx)+m*(1+c)+m))^2))*(1/2*m*zz/cos(beta)-m*(1+c)-m+trajpar*(m*(ha+xx)+m*(1+c)+m))/(m*zz*cos(bet a)*cos(alfa))-arccos(1/2*m*zz*cos(beta)*cos(alfa)/(1/2*m*zz/cos(beta)-m*(1+c)-m+trajpar*(m*(ha+xx)+m*(1+c)+m)))

Wenn das von KAHN beschriebene ReihenfolgenPro/blem tatsächlich die Ursache ist, könnte es vorkommen, dass unter der Wurzel eine negative Größe steht, die eigentlich ohne Bedeutung ist, da sie nachfolgend mit Null multipliziert, also als Produkt Null wird. Wenn nun Pro/E aber keinen komplexen Zahlenraum berechnen kann, besteht die Gefahr, dass die Berechnung als fehlerhaft abgebrochen wird, bevor die Multiplikation mit Null durchgeführt wurde.
[Für weiter Interessierte/AUS]

Alles klar?

------------------
----------------
"Ich stimme mit der Mathematik nicht überein. Ich meine, daß die Summe von Nullen eine gefährliche Zahl ist."  (Stanislaw Jerzy Lec)

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

wenn ich die Zeit habe, knöpfe ich mir den ausführlich vor.
Bis dahin was ganz allgemeines:

Es hat mich schon so manches Mal vor verzweifelten Ersatzhandlungen bewahrt, eine lange Formel in den Beziehungen nach dem oben gezeigten Prinzip auseinander zu pflücken.
Da ich auch kein C-Guru bin und meine Programmiererfahrung auch schon graue Haare hat, bediene ich mich des Standardwerkes für C:
Kernighan/Richie "Programmieren in C" , Hanser Verlag, ISBN 3-446-15497-3 , um Anregungen zu finden.

Grundsätzlich gilt für das Programme schreiben:
Soviel wie möglich Wert auf Übersichtlichkeit legen.
/* <Kommentar> ist mehr als nur guter Stil, wenn ich Arbeiten weitergebe, verlange ich, dass die wichtigen Schritte beschrieben werden.
Nur soviel wie nötig in einem Schritt rechnen.
Irgendwie erinnert mich das an die 7er Regel 

Das schrittweise Errechnen von B im obigen Beispiel ist für meine Formeln in Beziehungen typisch.
Alternativ errechne ich auch vorab Subvariable nach dem Schema B1=... B2=... B3=... B=B1+B2/B3 oder ähnliches.
Diesen Ansatz würde ich auch für Deine Formel wählen.
Um die Geschichte mit der negativen Wurzel zu umgehen, würde ich eine IF-Schleife einbauen.

IF abc < 0
abc=0
ENDIF

Das ändert nichts am Ergebnis, wenn anschließend sowieso mit 0 multipliziert wird und bringt Dich ganz einfach aus der Verlegenheit.

Vielleicht hilft der Ansatz ja schon, sonst, wie schon gesagt später, dann zieh ich mir auch das Modell und die Formel rein ...

------------------
"If you are not living life on the edge, you are taking up too much space". . =>MfG Khan<= 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Formel.jpg

Zitat:

---

Original erstellt von K_H_A_N:
... eine lange Formel in den Beziehungen nach dem oben gezeigten Prinzip auseinander zu pflücken. ...

---

Hallo K_A_H_N:
In der Beziehung des ZugKEs sind die Gleichungen aus den einzelnen Schritten aufgebaut und kommentiert.
In der eigentlichen Berechnung wird aber leider die vollumfängliche Formel benötigt.

Die Ursache dafür liegt darin, dass in der Originalanwendung (DesignTOOLS) die Zahnlücke über UDF-Technik mit variablen Maßen weiter gegeben wird. Daher dürfen (im Gegensatz zum stark reduzierten Musterbeispiel) keinerlei Parameter definiert werden. Anderenfalls liese sich das UDF nicht mehr rückstandsfrei aus dem Modell entfernen.

Die Monster-Wurzelformel habe ich mit Hilfe von Maple (ich habe leider kein Mathcad) bei dem Versuch der Fehlerforschung ermittelt und nur zur Info in den Beitrag hinein kopiert. In Wirklichkeit dieht das Ding wie auf dem beigefügten Bild aus.

Aber ich wäre für eine Hilfestellung hier sehr dankbar.

------------------
----------------
"Ich stimme mit der Mathematik nicht überein. Ich meine, daß die Summe von Nullen eine gefährliche Zahl ist."  (Stanislaw Jerzy Lec)

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Da musst du wohl mal bei PTC anrufen....
Ich hab schrägverzahnte Stirnräder ebenfalls gemacht, auch mit variablem Zug-KE, die sehen für meinen Geschmack schon gut genug aus.

Um nochmal auf meine Frage zurückzukommen, weiß jemand, ob und ggf. wie man beim Mustern von z.B. Bezugspunkten auf einer Leitkurve den tatsächlichen Abstand mustern könnte?
Solange es nur einen Radius gibt, funktioniert die Variante die angewendet habe sehr gut (Bogenlänge über Beziehungen ausrechnen um realen Abstand zu erhalten).
Wenn noch ein zweiter und dritter Radius hinzukommt geht das nicht mehr so leicht.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

1) Geschmacklich gut aussehen, oder geometrisch exat für einen direkte Fertigung sind zwei ganz unterschiedliche Welten.
2) Toll dass Du auch ein Zahnrad kannst. Bei mir geht es letztlich um ein "Palloid-Spiralkegelrad mit breitenballiger Zahnflanke". Da wissen die PTCler wahrscheinlich nicht einmal, was das ist.
3) Deinen Beitrag hast Du "ARCSIN-Problem" genannt. Dazu wurde Dir Hilfe geboten und ich habe mich zu diesem Thema aufgesattelt. Wenn Du weitere Fragen zum Mustern hast, machst Du besser einen neuen Beitrag (z.B. "Kurven-Muster mit definiertem Abstand") auf.

------------------
----------------
"Ich stimme mit der Mathematik nicht überein. Ich meine, daß die Summe von Nullen eine gefährliche Zahl ist."  (Stanislaw Jerzy Lec)

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von Egoduck:
...Um nochmal auf meine Frage zurückzukommen, weiß jemand, ob und ggf. wie man beim Mustern von z.B. Bezugspunkten auf einer Leitkurve den tatsächlichen Abstand mustern könnte?

---

IMHO geht das ab WF3

------------------
Gruß
Udo                Keine Panik, Du arbeitest mit Pro/E! Und Du hast cad.de gefunden!   

Neu hier?      Verwundert über die Antworten?    Dann schnell nachfolgende Link durchlesen. 
� Richtig Fragen � Nettiquette � Suchfunktion � System-Info � 7er-Regel � Unities

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

siehe anderen Thread.

------------------
    "If you are not living life on the edge, you are taking up too much space". . =>MfG Khan<= 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

luecke_v1.prt.2.txt

Ich glaube fast, das Ganze ist wirklich etwas für die PTC-Hotline.
(Hier verwende ich aktuell WF2)

Ich habe im anhängenden Beispiel
1. die Beziehungen im ZugKe massiv reduziert (durch Einführung von lokalen Parametern)
2. die Zugvariable trajpar ausgehebelt und durch einen manuellen Wert ttt ersetzt. Damit kann man jeden Zwischenzustand des Profiles abfragen.

Scheinbar liegt die Ursache in einer nicht korrekten Arbeitsweise der IF-Abfrage.

Solange ich für ttt einen Wert>trajpar_grenz eintrage, ist der Radius>rge und es wird zuverlässig der untere IF-Bereich gerechnet.
Bei einem Wert ttt<trajpar_grenz (z.B. ttt=0) wird zunächst korrekterweise der obere IF-Bereich gerechnet (radius<=rge wird mit YES) bestätigt, aber dann wird trotzdem versucht, den unteren IF-Bereich zu rechnen. Darin ist aber der arccos von einem Wert größer 1 nicht definiert. (Daher der Eintrag unter dem Theam ARCSIN-Problem.)

Nachweisen lässt sich dieses Fehlverhalten dadurch, dass ich die Berechnungen des unteren IF-Bereiche auskommentiert habe und stattdessen diesselbe Berechnung, wie im oberen IF-Bereich, nur mit einem Offset von 10 versehen, eingetragen habe. Nun lässt sich das Modell regenerieren, nimmt aber den richtigen Wert aus dem oberen IF-Bereich.

Im Klartext heißt das: Obwohl die IF-Abfrage einen Berechnungsast eindeutig ausschließt, wird dieser doch duchgerechnet. Ist diese Berechnung (zwischenzeitlich) nicht definiert, gibt es einen Fehler, anderenfalls wird der richtige Wert aus dem zulässigen IF-Berechnungsast gesetzt.

Ob das die Freunde auf dem heißen Draht verstehen?

------------------
----------------
"Ich stimme mit der Mathematik nicht überein. Ich meine, daß die Summe von Nullen eine gefährliche Zahl ist."  (Stanislaw Jerzy Lec)

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Professor,

ich habe zwar keine Ahnung von WF aber wie wäre es mit etwas wie:

arccos(x-int(x))

statt

arccos(x)

(quasi als Umschiffung der Klippe)

Gruß, Torsten

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo,

ich war bisher der Meinung, dass 'if-else'-Konstruktionen in Beziehungen von Zug-KEs nicht erlaubt sind. Nach dem Beitrag habe ich es nochmal ausprobiert, und siehe da, es funktioniert doch. Der Übergang zwischen den einzelnen Abschnitten muss nur stetig sein.

Gruß Michael

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Moin,

hab mir das mal angesehen und die Klippe mit einer zusätzlichen If Abfrage umschifft. Vielleicht hilft es.

rdr=reg/radius
if rdr >1
rdr=1  /* Dummywert
endif
alfa_r=acos(rdr)

Damit tut es...

------------------
Beste Grüße,
Max

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Sorry, aber die Telekom hat mich zeitweise abgekoppelt.
Die Idee von BergMax wäre normalerweise praktikabel. Das besondere Problem für meine Anwendung ist, dass ich keine zusätzlichen Parameter einführen darf (s.o.). Aber vielleicht lässt sich das mit einem nur lokal auf Skizzenebene gültigen Parameter (rdr)umgehen. Das ist mir in der Skizze eines ZugKE bisher noch nicht gelungen. Da muss ich noch ein wenig testen.

Auf jeden Fall schon mal Danke für die Vorschläge.

------------------
----------------
"Ich stimme mit der Mathematik nicht überein. Ich meine, daß die Summe von Nullen eine gefährliche Zahl ist."  (Stanislaw Jerzy Lec)

[Diese Nachricht wurde von Wyndorps am 17. Apr. 2008 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

... das mit dem int() ginge nicht? (kein zus. Parameter)

Gruß, Torsten

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Moin,

nein int() geht nicht. Begründung: gibt's nicht!

Da kann man dann aber x=acos((rge/radius)-floor(rge/radius)) nehmen.

------------------
Beste Grüße,
Max

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Ich denke, der Prof. hat den Fehler auf ein Pro_Gramm-spezifisches Pro_Blem zurückführen können!?

ansonsten: warum nicht x = acos(abs(y)), wenn y als negativer Wert sowieso genullt wird?

Basti

------------------

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von Pro_Blem:
Ich denke, der Prof. hat den Fehler auf ein Pro_Gramm-spezifisches Pro_Blem zurückführen können!?

ansonsten: warum nicht x = acos(abs(y)), wenn y als negativer Wert sowieso genullt wird?

Basti

---

Weil das Vorzeichenproblem erst bei der internen Wurzelnäherung auftritt, die ich als mathematische Ursache vermute. Tatsächlich muss abgefangen werden, dass 0<=y<=1 auch für alle Zwischenschritte der acos-Funktion gewährleistet bleibt.

------------------
----------------
"Ich stimme mit der Mathematik nicht überein. Ich meine, daß die Summe von Nullen eine gefährliche Zahl ist."  (Stanislaw Jerzy Lec)

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

formel01.jpg

Der Ansatz von BergMax funktioniert in dem Fall, dass ich Einzelvariablen (Parameter) vergeben kann.
Soll das, wie bereits begründet nicht geschehen, ergibt sich die abgebildete Formel für die Evolventenlücke.

Wird diese wiederum in Pro/E eingesetzt, habe ich dasseleb Pro/blem wie vorher.

Die einzige Lösung scheint demnach die Verwendung einzelner Variablen zu sein. Daraus ergibt sich ein Problem, dass vielleicht am Besten in einen eigenen neuen Beitrag geschrieben wird:

Ich kann zwar Variablen auf KE-Ebene definieren, diese aber in der Skizze desselben KEs nicht verwenden. hier stehen mir nur die teilbezogenen Parameter zur Verfügung. Ich meine, da gab es einen Trick. Leider wirft mir die CAD.DE-Suche nach "KE-Parameter" alle Ergebnisse mit dem Begriff "Parameter" aus, was etwas unübersichtlich ist.
[Neuer Beitrag erstellt]
------------------
----------------
"Ich stimme mit der Mathematik nicht überein. Ich meine, daß die Summe von Nullen eine gefährliche Zahl ist."  (Stanislaw Jerzy Lec)

[Diese Nachricht wurde von Wyndorps am 17. Apr. 2008 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP