|
|
|
Simulation eines Zerspankraftmodells |
|
| Codename |
Forum-Anfänger
|
 |
Beiträge: 27
|
|
|
|
Anmeldedatum: 16.07.15
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
 |
|
Verfasst am: 16.07.2015, 08:33
Titel: Simulation eines Zerspankraftmodells
|
 |
Hallo zusammen,
für meine Bachelorarbeit möchte ich gerne eine Simulation eines Zerspankraftmodells erstellen. Den dafür geschriebenen Quellcode habe ich als Textdatei angehängt. Simuliert wird dort ein Schlichtfräsprozess mit einem Kugelkopfwerkzeug.
Diese funktioniert auch teilweise schon ganz gut, jedoch sind die berechneten Zerspankräfte im Vergleich zu den real gemessenen Verläufen zu groß (Faktor 5) und der Zahneingriffsbereich ist auch ca. 10° zu groß.
Ich vermute, dass der Fehler in den For-Schleifen steckt.
Über Verbesserungsvorschläge würde ich mich sehr freuen.
Viele Grüße
| Beschreibung: |
|
Download |
| Dateiname: |
Zerspankraftmodell.txt |
| Dateigröße: |
4.14 KB |
| Heruntergeladen: |
822 mal |
|
|
|
|
|
|
| Jan S |
Moderator
|
|
Beiträge: 11.057
|
|
|
|
Anmeldedatum: 08.07.10
|
|
|
|
Wohnort: Heidelberg
|
|
|
|
Version: 2009a, 2016b
|
|
|
|
|
|
|
Verfasst am: 16.07.2015, 11:44
Titel: Re: Simulation eines Zerspankraftmodells
|
|
Hallo Codename,
Wenn Du das leidige
clear all
weglässt, kannst Du den Debugger verwenden, um Zeile für Zeile durch den Code zu gehen und zu untersucghen, was genau passiert.
| Zitat: |
| Diese funktioniert auch teilweise schon ganz gut, jedoch sind die berechneten Zerspankräfte im Vergleich zu den real gemessenen Verläufen zu groß (Faktor 5) und der Zahneingriffsbereich ist auch ca. 10° zu groß. |
Es ist unwahrscheinlich, dass jemand das Problem findet, solange ja nur der Code vorliegt, der nicht macht, was er soll.
Gruß, Jan
|
|
|
|
| Epfi |
Forum-Meister
|
|
Beiträge: 1.134
|
|
|
|
Anmeldedatum: 08.01.09
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 16.07.2015, 12:26
Titel:
|
|
| |
 |
 |
@Jan: clear all löscht die break points im aufrufenden Skript erst nachdem das Skript durchgelaufen ist. Ein Debuggen ist also sehr wohl möglich, nur etwas nervig, weil man alle Break Points immer wieder neu setzen muss. Die Aussage, dass Debuggen durch
clear all
unmöglich ist, wird nicht richtiger, wenn man sie andauernd wiederholt - das Debuggen wird nur nervig.
Ansonsten ist der Code doch prima dokumentiert und nachvollziehbar - selbst, wenn man keine Ahnung von Zerspanungsmechanik hat.
@Codename: Guck Dir mal
linspace
an, das spart Dir ne Menge Zeilen an Code.
i und j als Laufvariablen zu benutzen ist etwas unglücklich, weil beides auch die imaginäre Einheit bezeichnet. Wenn man sich da mal vertut bekommt man sehr wunderliche Fehlermeldungen.
Ich würde auf jeden Fall nochmal prüfen, ob Du Dich nicht irgendwo mal mit den Winkel-Umrechnungen (rad/deg) vertan hast.
Was ist denn Deine Referenz? Also woher weißt Du, was rauskommen sollte? Wenn es Messungen sind, solltest Du nicht unbedingt davon ausgehen, dass die Parameter, die an der Maschine eingestellt wurden, auch wirklich so umgesetzt wurden.
Und wo kommen die Kraftkoeffizienten her? Sind die wirklich so genau, wie sie da stehen oder sind das irgendwelche Erfahrungswerte, die man eigentlich nur als groben Anhaltspunkt nehmen kann?
|
|
|
|
| laternenjoe |
Forum-Fortgeschrittener
|
|
Beiträge: 83
|
|
|
|
Anmeldedatum: 25.02.15
|
|
|
|
Wohnort: Bochum
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 16.07.2015, 13:50
Titel:
|
|
|
Oder ist eventuell irgendwo bei den Kraftkoeffizienten oder Längenangaben zu Beginn ein Eineitenfehler drin? Weil du die Längenangaben am Anfang in mm machst und ich am Ende nirgendswo sehe, wo das in m umgerechnet wird. Oder ist das schon berücksichtigt?
|
|
|
|
| Codename |
Themenstarter
Forum-Anfänger
|
|
Beiträge: 27
|
|
|
|
Anmeldedatum: 16.07.15
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 16.07.2015, 17:41
Titel:
|
|
| |
|
|
Hallo zusammen,
erstmal vielen Dank für eure Antworten.
@Jan: Könntest du mir kurz das Vorgehen mit dem Debugger beschreiben? Ich habe diese Funktion bisher noch nicht benutzt.
@Epfi: Danke für den Tipp mit linsapce. Der Code wird dadurch insgesamt kompakter aber mein Problem löst das leider nicht. Die Winkel-Umrechnungen habe ich bereits geprüft. Es ist doch richtig, dass Matlab jeweils die Einheit Rad erwartet, also gerade bei den trigonometrischen Funktionen? Meine Referenzen sind Messungen, die ich mit den gleichen Prozess- und Stellgrößen durchgeführt habe. Natürlich bin ich mir bewusst, dass es zu Abweichungen aufgrund von Ungenauigkeiten und Toleranzen kommen muss, jedoch ist dadurch nicht der Faktor 5 erklärbar. Die Kraftkoeffizienten wurden in einer anderen Versuchsreihe bestimmt. Ich bin mir sehr sicher, dass diese für meinen Fall "richtig" sind.
@laternenjoe: Die Längenangaben wurden alle in mm angegeben wie du richtig festgestellt hast. Eine Umrechnung in m wird an keiner Stelle durchgeführt. Die Kraftkoeffizienten haben die Einheit [N/mm] bzw. [N/mm²]:
Mir ist noch die folgende Zeile aufgefallen:
phi=phi0(i)+(k-1)*2*pi/Ztotal-z(j)*tan(io)/R;
Der letzte Term dieser Gleichung (z(j)*tan(io)/R) ist einheitenlos, wohingegen die anderen Terme in Rad angegben sind. Müssten ich diesen Term vielleicht noch in Rad umrechnen?
Ansonsten würde ich gerne generell von euch wissen, ob die For-Schleifen und die Diskretisierung, unabhängig vom Inhalt, programmiertechnisch Sinn machen. Ich habe zuvor nie mit Matlab gearbeitet, weswegen ich an dieser Stelle unsicher bin.
Vielen Dank
|
|
|
|
| Epfi |
Forum-Meister
|
|
Beiträge: 1.134
|
|
|
|
Anmeldedatum: 08.01.09
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 16.07.2015, 18:02
Titel:
|
|
| |
|
|
| Codename hat Folgendes geschrieben: |
| jedoch ist dadurch nicht der Faktor 5 erklärbar. |
Sag das nicht... Zum einem sind Modelle in der Regel unter diversen Annahmen entstanden, die nicht immer alle uneingeschränkt zutreffen und zum anderen funktionieren Messungen eh nur selten so, wie man denkt. Und nur weil Du einer Maschine sagst, dass sie 100mm/min Vorschub machen soll, heißt das nicht, dass es nicht vielleicht 101mm/min sind. Da wäre ich wirklich sehr vorsichtig mit falsch angenommenen Genauigkeiten, die man gar nicht hat. Darum fragte ich auch wegen der Koeffizienten, die ja nun wirklich unglaublich genau bekannt sind.
| Zitat: |
Der letzte Term dieser Gleichung (z(j)*tan(io)/R) ist einheitenlos, wohingegen die anderen Terme in Rad angegben sind. Müssten ich diesen Term vielleicht noch in Rad umrechnen?
|
Das ist zumindest eine Auffälligkeit, aber umzurechnen gibt es da nichts. Entweder es ist ein Winkel oder nicht. Eine Umrechnung von dimensionslos nach Winkel macht nur wenig Sinn. Die Formel vielleicht nochmal aus zweiter Quelle bestätigen? Wobei die Maschinenbauer ja ab und zu auch schon mal ein Auge zudrücken, wenn irgendwas mit den Einheiten nicht hinhaut...
| Zitat: |
Ansonsten würde ich gerne generell von euch wissen, ob die For-Schleifen und die Diskretisierung, unabhängig vom Inhalt, programmiertechnisch Sinn machen. Ich habe zuvor nie mit Matlab gearbeitet, weswegen ich an dieser Stelle unsicher bin.
|
Die Schleifen funktionieren so. In der innersten Schleife hast Du aber einen Kommentar stehen, dass etwas integriert werden soll. Eine Integration kann ich aber in der Schleife nicht entdecken. Dafür berechnest Du DFt, DFr und DFa jeweils zwei mal und zwar auf verschiedenen Wegen. Der Einrückung nach tippe ich darauf, dass Dir da das
end
aus versehen zu weit runtergerutscht ist und das in Zeile 105 stehen sollte und nicht erst in Zeile 137.
|
|
|
|
| Codename |
Themenstarter
Forum-Anfänger
|
|
Beiträge: 27
|
|
|
|
Anmeldedatum: 16.07.15
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 16.07.2015, 18:35
Titel:
|
|
| Zitat: |
| Die Formel vielleicht nochmal aus zweiter Quelle bestätigen? |
Der Term z(j)*tan(io)/R wird in diversen Quellen so angegeben. Es macht wirklich keinen Sinn diesen umzurechnen, da er dimensionslos ist.
| Zitat: |
| In der innersten Schleife hast Du aber einen Kommentar stehen, dass etwas integriert werden soll. Eine Integration kann ich aber in der Schleife nicht entdecken. |
Laut Quelle sollen an dieser Stelle die differentiellen Kraftanteile entlang der z-Achse aufintegriert werden. Statt einer Integration bilde ich die Summe über ganz viele dz, was im Grunde einer Integration entspricht. Liege ich da falsch?
| Zitat: |
| Dafür berechnest Du DFt, DFr und DFa jeweils zwei mal und zwar auf verschiedenen Wegen. |
Die oberen Gleichungen sind auskommentiert. Berechnet werden die Kräfte nur auf einem Weg.
|
|
|
|
| Epfi |
Forum-Meister
|
|
Beiträge: 1.134
|
|
|
|
Anmeldedatum: 08.01.09
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 16.07.2015, 18:43
Titel:
|
|
| Zitat: |
| Laut Quelle sollen an dieser Stelle die differentiellen Kraftanteile entlang der z-Achse aufintegriert werden. Statt einer Integration bilde ich die Summe über ganz viele dz, was im Grunde einer Integration entspricht. Liege ich da falsch? |
Nein, alles gut. Hatte eine Lauf-Index-Verwirrung. In Zeile 134 integrierst Du ja.
| Zitat: |
| Die oberen Gleichungen sind auskommentiert. Berechnet werden die Kräfte nur auf einem Weg. |
Da hat mein Editor den Kommentar nicht angemalt. Sorry.
Dann müsste das eigentlich schon passen so.
|
|
|
|
| Codename |
Themenstarter
Forum-Anfänger
|
|
Beiträge: 27
|
|
|
|
Anmeldedatum: 16.07.15
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 16.07.2015, 18:47
Titel:
|
|
Was sagst du zu der If-Bedingung. Macht sie aus deiner Sicht Sinn?
|
|
|
|
| Epfi |
Forum-Meister
|
|
Beiträge: 1.134
|
|
|
|
Anmeldedatum: 08.01.09
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 16.07.2015, 21:19
Titel:
|
|
Die war so lang, dass ich sie bis jetzt überlesen habe ;) Aber das sieht eigentlich gut aus. Wenn phi größer als der Eintrittswinkel und (Matlab sieht es gerne, wenn Du an der Stelle && verwendest statt &) und phi kleiner als der Austrittswinkel ist, dann ist es im Eingriff. Klingt logisch.
Ich würde nach wie vor auf die Parameter tippen. Probier doch mal ein bisschen rum, wie empfindlich die Ergebnisse auf kleine Änderungen der einzelnen Parameter reagieren und überlege, wie wahrscheinlich es ist, dass die Parameter mit großem Einfluss mit Fehlern behaftet sind. Beispielsweise hat die Tangens-Funktion im Bereich um pi/2, 3*pi/2, ... großes Potenzial, aus kleinen Eingangsänderungen sehr große Änderungen am Ausgang zu erzeugen.
|
|
|
|
| laternenjoe |
Forum-Fortgeschrittener
|
|
Beiträge: 83
|
|
|
|
Anmeldedatum: 25.02.15
|
|
|
|
Wohnort: Bochum
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 17.07.2015, 08:04
Titel:
|
|
|
Ich kann jetzt auch nur mehr oder weniger raten, aber vllt mal die Auflösung M größer machen, wenn du das noch nicht ausprobiert hast? Oder L größer machen?
|
|
|
|
| Jan S |
Moderator
|
|
Beiträge: 11.057
|
|
|
|
Anmeldedatum: 08.07.10
|
|
|
|
Wohnort: Heidelberg
|
|
|
|
Version: 2009a, 2016b
|
|
|
|
|
|
|
Verfasst am: 19.07.2015, 11:38
Titel:
|
|
Hallo Codename,
| Zitat: |
| @Jan: Könntest du mir kurz das Vorgehen mit dem Debugger beschreiben? Ich habe diese Funktion bisher noch nicht benutzt. |
Matlab's Dokumentation erklärt das umfassend. Suche dort nach "Breakpoint" und "debug". Z.B. http://www.mathworks.com/help/matlab/debugging-code.html
Die Entwicklung und das Testen eines Programms ist ohne Debugging kaum vorstellbar, also lohnt es sich auf alle Fälle, die entsprechenden Kapitel durchzuarbeiten.
Gruß, Jan
|
|
|
|
| Jan S |
Moderator
|
|
Beiträge: 11.057
|
|
|
|
Anmeldedatum: 08.07.10
|
|
|
|
Wohnort: Heidelberg
|
|
|
|
Version: 2009a, 2016b
|
|
|
|
|
|
|
Verfasst am: 24.07.2015, 14:28
Titel:
|
|
Hallo Epfi,
| Zitat: |
| @Jan: clear all löscht die break points im aufrufenden Skript erst nachdem das Skript durchgelaufen ist. Ein Debuggen ist also sehr wohl möglich, nur etwas nervig, weil man alle Break Points immer wieder neu setzen muss. Die Aussage, dass Debuggen durch
clear all
unmöglich ist, wird nicht richtiger, wenn man sie andauernd wiederholt - das Debuggen wird nur nervig. |
Du hast vollkommen recht damit, dass die Breakpoints im aufrufenden Script oder in der aufrufenden Funktion erst gelöscht werden, wenn sie beendet wird. Danke für den Hinweis. Die Breakpoints in Unterfunktionen oder anderen Funktionen/Scripts sind aber betroffen, und das ist eine deutliche Behinderung.
Wenn ein Programmieranfänger aber noch gar nicht weiß, wie man mit dem Debugger umgeht, ist ein "nur nervig" schon eine ernste Einschränkung.
Ich werde deshalb auch weiterhin raten,
clear all
wegzulassen und nur noch sagen, dass es das Debuggen unnötig erschwert.
Gruß, Jan
|
|
|
|
| Epfi |
Forum-Meister
|
|
Beiträge: 1.134
|
|
|
|
Anmeldedatum: 08.01.09
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 24.07.2015, 14:39
Titel:
|
|
|
Danke :) Und es löscht natürlich auch alle gecachten Funktionen und macht damit das Programm langsamer. Nur falls man mal einen Grund braucht, wenn jemand sagt, dass er gar nicht debuggen möchte ;)
|
|
|
|
|
|
|
Einstellungen und Berechtigungen
|
|
Du kannst Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
Du kannst Dateien in diesem Forum posten
Du kannst Dateien in diesem Forum herunterladen
|
|
Impressum
| Nutzungsbedingungen
| Datenschutz
| FAQ
|  RSS
Hosted by:
Copyright © 2007 - 2024
goMatlab.de | Dies ist keine offizielle Website der Firma The Mathworks
MATLAB, Simulink, Stateflow, Handle Graphics, Real-Time Workshop, SimBiology, SimHydraulics, SimEvents, and xPC TargetBox are registered trademarks and The MathWorks, the L-shaped membrane logo, and Embedded MATLAB are trademarks of The MathWorks, Inc.
|
|
