GCode Programmierung für 3D in C++, Ein Projekt

Bei der Programmierung hänge ich derzeit fest, weil ich ein typischer G91 Programmierer bin.

GEBT MIR G_CODE IN G91, und ich sehe vor dem Auge, was da läuft.

Sobald da G90 draufsteht, hänge ich auf dem Schlauch, keine anschauliche Vorstellung mehr, daher paßt das jetzt noch nicht, ist ja auch schon spät.

Aber wie das im Prinzip geht, sieht man hier:

case kegel:
{
std::ofstream out(wks->dateiname_gcode);
sprintf(buffer, "(Algorithmus für Kegel 450 Grad Radius= %f )\n",wks->radius );
out << buffer;
sprintf(buffer,"G90 (Offset Mittelpunkt Kegel X %f y%f ) \n",wks->mittelpunkt_offset_g90.x,wks->mittelpunkt_offset_g90.y);
out << buffer;
sprintf(buffer,"G0 X%f Y%f Z20 (Startpunkt)\n",krd->xg90+20, krd->yg90);
out <<buffer;
sprintf(buffer,"G1 X%f Z0 F100 (an die Kontur fahren)\n",krd->xg90);
out <<buffer;

// Hier beginnt die Schleife, die alle Datensätze einliest:

for (int k=0;k<wks->zustellungen;k++)
{
sprintf(buffer, "G2 X0 Y%f I%f Z%f (VK Ramp 3Uhr)\n",krd->yg90-krd->xp,krd->xp*(-1),wks->z_zustellung);
out << buffer;
sprintf(buffer, "G2 X0 Y%f J%f (HK 6-12Uhr)\n",krd->xg90,krd->xp);
out << buffer;
sprintf(buffer, "G2 X%f Y0 J-%f (VK 12-3Uhr)\n",krd->xg90,krd->xp);
out << buffer;


/*(FRÄSBAHN #1 beginnend bei 3 Uhr)
(GRundfläche ist 50 Radius, Mittelpunkt bei 0.0)
g2 x0 y-45 i-45 z1(Viertelkreis Rampe in x und z von 3 nach 6)
g2 x0 y45 j45 (Halbkreis 6 nach 12)
g2 x45 y0 j-45 (Viertelkreis 12 nach 3)
G1 z0 (Absenken bei 3 Uhr)
g2 x0 y-45 i-45 (Viertelkreis rampe räumen 3 nach 6 )
g1 z1 (anheben)
*/

Wir öffnen mit ofstream out erstmal die passende Datei, schreiben dann mit out<< erstmal ein paar Zeilen Kommentar, und dann beginnen wir, das Ding, was unten als Kommentar eingefügt ist, der G-Code von einem anderen Beispiel, ins Programm zu übernehmen. Das Problem ist, wir können keine Rechenoperationen machen, sondern müssen aus den Zahlen Zeichen machen und die hintereinander so anordnen, daß G-Code herauskommt.

Wir definieren einen string, eine Zeile von 80 zeichen namens buffer.

Und da schreiben wir rein, was wir brauchen, nämlich

G2 X%fließkommazahl Y%fließkommazahl I%fließkommazahl J%fließkommazahl z%Fließkommazahl,

ist schon sehr genial gelöst von Ritchie, diese sprint() Funktion.

Wo dann das %f steht (f=float, Fließkommazahl), setzt das Programm anschließend die echten zahlen ein, also so:

sprintf(speicherplatz," was man so will %f und wie auch immer %f ",zahl1, zahl2);

Es ist schon schwer, C nicht zu lieben. Das ist eine so schöne Sprache, das glaubt man nicht, daß sich ein Mensch sowas ausdenken konnte.

Aber die g90 Version schaffe ich heute abend nicht mehr. Wäre das in G91, wär das schon fertig. Aber wir sollen ja, wie Matthias sagte, in g90 Programmieren.

Da hat er allerdings in dem Punkt recht: ich sehe auch gern auf der Steuerung, was die Maschine so vorhat.

Bei meiner steuerung, was die so in g91 macht, das zeigt die Maschine nicht an. Kann sie nicht rechnen. Mit g90 ist man da schon auf der sichereren Seite.

Der Beitrag wurde von sharky bearbeitet: 25.01.2009, 23:16 Uhr

Huch, den Beitrag hatte ich gar nicht gesehen!

Ja, das mit den Anfahrbögen könnte man so optimieren, daß sich das mit den 90 Grad mehr nichts tut, völlig richtig, also auf einer kleinen Fräse und im Hinblick auf den Gesichtspunkt "Pattern" (noch nie gehört, aber du wirst schon wissen, was du sagst) dann wohl eher ehrlich in 2 D auf der Ebene anfahren. Krieg ich hin. Ich mach da Anfahrbögen, da paßt keine Maus mehr dazwischen.

Richtige Helix in 3 D krieg ich nicht mangels "intellektueller Neugierde" nicht hin, sondern weil mir die passende Steuerung fehlt, die etwa Spirale fahren kann. Hab ich schon abgehakt, 3D-Helix ist nicht drin.

Eine just-in-time Steuerung kann meine Steuerung auch nicht, kannste auch abhaken. Die macht nichts als G-Befehle hintereinander ableiern. Und ich kann auch nicht für einen Durchgang um den Kegel herum der Steuerung 5 Mio. (das sagt c, Peter the Pointer) oder 500000 (da wär Peter schon der Meinung, schlechte Auflösung) oder 5000 oder 500 G2-Befehle reinknallen, erstickt die steuerung dran. Die Umstellung auf g15 ist auch keine wirkliche Lösung, weil auch das wieder in der Datei hängt. g15 macht keinen kleineren Code als g90/g91.

Eine gute Steuerung, die das Problem zur Laufzeit errechnen würde, wäre hier der Königsweg. So eine Steuerung hab ich nicht.

Was dann bleibt, ist ehrlich in 2 D anzufahren.

Ist aber wie du sagst, vom "Praktischen" her auch gar nicht so die schlechte Lösung.



Gruß Sharky

Der Beitrag wurde von sharky bearbeitet: 25.01.2009, 23:48 Uhr

Tja, noch bist du nicht der einzige, der sich an deinem Thread beteiligt.
Gelesen wird er jedoch offensichtlich ganz fleißig. Bislang 2118 Zugriffe.

Ich habe schon ein paar PNs zum Thema bekommen - und zwar von Leuten, die sich bislang noch nicht am Thread beteiligt haben.

deshalb @all:
Das ist hier ein Forum, und der Sinn eines Forums besteht nach meiner Meinung nicht darin, daß Einige hinter'm Vorhang tuscheln, sondern darin, daß man sich öffentlich austauscht. Ich werde deshalb in dieser Sache keine persönlichen Nachrichten mehr beantworten. Schreibt's doch hier.


Gruß,

Clemens

*******************************************
*******************************************

DIE PERFEKTE 3D-HELIX


*******************************************

mit einem c-Compiler zu berechnen, ist natürlich Kinderkram. Dafür muß sich der Compiler wirklich nicht warmlaufen.

C ist eine ALL PURPOSE PROGRAMMING LANGUAGE

man kann wirklich alles damit machen, und was man mit C macht, läuft auch sauschnell, weil die Sprache nahe an der Maschine ist.

Das Programm habe ich hinten drangehängt, es ist lauffähiger c-Code, der noch noch kompiliert werden muß und ab gehts!
Ich will die Logik mal kurz erklären:

Wir fahren den Vollkreis ab beginnend irgendwo, egal, hier weil so üblich ab 3 Uhr gegen den Uhrzeigersinn.

Wir legen vorher fest, um welchen Betrag sich der Radius am ende eines Vollkreises verringern soll (soll ja ´ne Helix werden), und zugleich die Steigung in Z.

Die Auflösung sagt uns, wieviele Punkte wir berechnen wollen. Damit man am Bildschirm sehen kann, was das PRogramm macht, habe ich mal einen Durchlauf mit 36 Punkten =10 Grad Winkelschritt ankopiert.

Um jetzt die Fräsbahn in einer Auflösung von 10.000 Punkten pro Vollkreis zu berechnen, brauchen wir nur die Konstante auflösung von 36 auf 10.000 zu setzen, alles andere macht das Programm automatisch.

Nur was machen wir mit den Daten?

Würden wir daraus G-Code erzeugen, hätten wir für einen Durchgang 10.000 Datensätze. Man muß gar nicht ausrechnen, was das für SPeicher kostet. Errechnet man die Helix also im Voraus, um sie in einer Datei abzuspeichern, hat man soviele Daten, daß man damit leicht jede Festplatte knacken kann.

Diese Helix ist ein MUSTERBEISPIEL dafür, daß es viel besser ist, wenn die STeuerung JUST IN TIME die Maschine steuert, also keinen G-Code einliest, sondern die Berechnung zur Laufzeit vornimmt.

Mein C-Compiler könnte das! Für die 10000 Punkte zu berechnen, braucht der vielleicht eine Millisekunde.

Würde man also das PRogramm irgendwie an die Maschine ranklemmen können, hätte ich die perfekte Helix.

Im Prinzip ist MACH3 ja eine PC-gestützte Maschinensteuerung. Nur leider nicht open source, der Anwender kann das Programm nicht verändern.

Es wäre aber vielleicht denkbar, daß Mach3 anstelle einen Zyklus einzulesen, genausogut einen C-Baustein einlesen könnte, ich muß mich da mal schlau machen.




Gruß Sharky



Hier das Programm, der Code ist vollständig und lauffähig


#include <cstdlib>
#include <iostream>
#include <math.h>
using namespace std;
double sin_grad(double winkel);
double cos_grad(double winkel);
double const pi=3.1416;

int main(int argc, char *argv[])
{
int const aufloesung = 36;
double const zustellung_z =0.1;
double const zustellung_radius=0.1;

double radius=100;
double delta_z=zustellung_z/aufloesung;
double delta_radius=zustellung_radius/aufloesung;
double winkelschritt = 360.0/aufloesung;

double x[aufloesung], y[aufloesung],z[aufloesung], winkel;

winkel=0;

for (int k=0;k<aufloesung;k++) z[k]=(k+1)*delta_z;
for (int k=0;k<aufloesung;k++)
{

y[k]=sin_grad(winkel)*radius;
x[k]=cos_grad(winkel)*radius;
printf("Radius=%f Winkel=%f X=%f Y=%f Z=%f\n",radius, winkel, x[k],y[k],z[k]);
winkel=winkel+winkelschritt;
radius=radius-delta_radius;


}
system("PAUSE");
return EXIT_SUCCESS;
}


double sin_grad(double winkel)
{
double zahl;
zahl=sin(winkel*pi/180);
return(zahl);
}

double cos_grad(double winkel)
{
double zahl;
zahl=cos(winkel*pi/180);
return(zahl);
}


/* Hardcopy vom Bildschirm für aufloesung=36 (10 Grad Schritte)

Vollkreis 360 Grad beginnend bei 3 Uhr gegenläufig richtung 12-9-6 Uhr

Radius=100.000000 Winkel=0.000000 X=100.000000 Y=0.000000 Z=0.002778
Radius=99.997222 Winkel=10.000000 X=98.478033 Y=17.364376 Z=0.005556
Radius=99.994444 Winkel=20.000000 X=93.964014 Y=34.200191 Z=0.008333
Radius=99.991667 Winkel=30.000000 X=86.595262 Y=49.995939 Z=0.011111
Radius=99.988889 Winkel=40.000000 X=76.595828 Y=64.271744 Z=0.013889
Radius=99.986111 Winkel=50.000000 X=64.269677 Y=76.593936 Z=0.016667
Radius=99.983333 Winkel=60.000000 X=49.991455 Y=86.588229 Z=0.019444
Radius=99.980556 Winkel=70.000000 X=34.195096 Y=93.951088 Z=0.022222
Radius=99.977778 Winkel=80.000000 X=17.360637 Y=98.458947 Z=0.025000
Radius=99.975000 Winkel=90.000000 X=-0.000367 Y=99.975000 Z=0.027778
Radius=99.972222 Winkel=100.000000 X=-17.360396 Y=98.453349 Z=0.030556
Radius=99.969444 Winkel=110.000000 X=-34.191985 Y=93.940396 Z=0.033333
Radius=99.966667 Winkel=120.000000 X=-49.983757 Y=86.573428 Z=0.036111
Radius=99.963889 Winkel=130.000000 X=-64.255955 Y=76.576441 Z=0.038889
Radius=99.961111 Winkel=140.000000 X=-76.575021 Y=64.253326 Z=0.041667
Radius=99.958333 Winkel=150.000000 X=-86.566762 Y=49.978637 Z=0.044444
Radius=99.955556 Winkel=160.000000 X=-93.927721 Y=34.186200 Z=0.047222
Radius=99.952778 Winkel=170.000000 X=-98.434391 Y=17.355935 Z=0.050000
Radius=99.950000 Winkel=180.000000 X=-99.950000 Y=-0.000734 Z=0.052778
Radius=99.947222 Winkel=190.000000 X=-98.428665 Y=-17.356416 Z=0.055556
Radius=99.944444 Winkel=200.000000 X=-93.916778 Y=-34.183780 Z=0.058333
Radius=99.941667 Winkel=210.000000 X=-86.551594 Y=-49.971575 Z=0.061111
Radius=99.938889 Winkel=220.000000 X=-76.557054 Y=-64.240167 Z=0.063889
Radius=99.936111 Winkel=230.000000 X=-64.236975 Y=-76.556106 Z=0.066667
Radius=99.933333 Winkel=240.000000 X=-49.965819 Y=-86.545295 Z=0.069444
Radius=99.930556 Winkel=250.000000 X=-34.177305 Y=-93.904354 Z=0.072222
Radius=99.927778 Winkel=260.000000 X=-17.351232 Y=-98.409834 Z=0.075000
Radius=99.925000 Winkel=270.000000 X=0.001101 Y=-99.925000 Z=0.077778
Radius=99.922222 Winkel=280.000000 X=17.352436 Y=-98.403981 Z=0.080556
Radius=99.919444 Winkel=290.000000 X=34.175574 Y=-93.893160 Z=0.083333
Radius=99.916667 Winkel=300.000000 X=49.959393 Y=-86.529760 Z=0.086111
Radius=99.913889 Winkel=310.000000 X=64.224378 Y=-76.537667 Z=0.088889
Radius=99.911111 Winkel=320.000000 X=76.537190 Y=-64.220625 Z=0.091667
Radius=99.908333 Winkel=330.000000 X=86.523828 Y=-49.953001 Z=0.094444
Radius=99.905556 Winkel=340.000000 X=93.880987 Y=-34.168410 Z=0.097222
Radius=99.902778 Winkel=350.000000 X=98.385278 Y=-17.346530 Z=0.100000
Drücken Sie eine beliebige Taste . . .
*/

Der Beitrag wurde von sharky bearbeitet: 26.01.2009, 09:36 Uhr

Mir fällt gerade auf, daß ich pi sehr lieblos mit 3.1416 definiert habe.

Wenn man eine Helix auf 6 Stellen hinter dem Komma berechnen will, sollte man natürlich bei pi auch ein paar Stellen zugeben.

Zum Datentyp

double

Double ist wie float eine Fließkommazahl, sie hat aber ein größeres Format im Speicher, wie groß, hängt vom Betriebssystem ab (C läuft ja auch auf Unix u.a.).

Ich hab mal einen Blick drauf geworfen, wie der dev-Compiler diese Fließkommazahlen verwaltet.

Wir haben bei float eine Genauigkeitsgrenze von 5 Nachkommastellen.

Die Genauigkeit von double ist mindestens 6 Nachkommastellen, wahrscheinlich noch viel größer.

Mit 6 Nachkommastellen sind wir im Bereich 1 NANOMETER, also von der Rechengenauigkeit her brennt da nichts an.

Was aber unbedingt erfolgen müßte, daß man die Rundung der nachkommastellen (hier wurde nicht gerundet) an die Leistung der Steuerung anpaßt bzw. auch überlegt, was davon die Spindel auch umsetzen kann.

Und es gibt noch eine Unsauberkeit mit Z.

Wenn wir mit

double delta_z=zustellung_z/aufloesung;

Die Z-Zustellung auf die Anzahl der Gesamtzustellungen aufteilen, ist uns vom Logischen her ein Fehler unterlaufen, weil die Anzahl der Zustellungen in z nicht aufloesung ist, sondern aufloesung-1. Wir haben ja unten herum, bei Z =NULL, gar keine Zustellung.

Daher müssen wir diese kleine Zeile wie folgt ändern:

double delta_z=zustellung_z/(aufloesung -1);

und weisen die Werte so zu:

for (int k=1;k<aufloesung;k++) z[k]=k*delta_z;

Diese beiden Programmzeilen geändert, müßte es ticken.

Ob bei der Wertzuweisung in x/y auch so ein "einen daneben" FEhler drin ist, muß ich heute abend mal nachsehen.

Man muß beim Programmieren immer auf die Extremwerte sehen. In der Mitte läuft alles rund, die kritischen Punkte sind erster und letzter. Kann ich aber vor heute abend nicht machen.

Der Beitrag wurde von sharky bearbeitet: 26.01.2009, 10:38 Uhr

Tja, mit der Logik ist das so eine Sache.

Nochmal neu:

Wenn wir den Kegel von ganz unten beginnen, bei z=0, müssen wir die geforderte Gesamtzustellung in z auf n-1 verteilen, sonst kommen wir am Ende des Durchgangs nicht an den Wert der Steigung heran.

Wenn Steigung in z = 36 wäre, und wir fahren 36 Durchgänge, davon einen bei Z=0, hätten wir bei n=36-1 (!!!!) die Zustellung 35 erreicht, aber nicht 36.

Wenn wir das allerdings so umformulieren:

delta_z=Gesamtzustellung/35, wie oben geschrieben, verändern wir die Steigung. Wir haben dann eine Helix mit einer Steigung Gesamt/35 anstatt Gesamt/36

Das Problem kann man nur folgendermaßen lösen:

Es bleibt bei Gesamt/auflösung

Und den einmaligen Nulldurchgang, am Anfang der Bearbeitung, müssen wir als getrennten Befehl zusätzlich erzeugen, außerhalb der Zählschleife.

Sähe dann so aus:

Fahre Nulldurchgang Z=0

Anfang Zählschleife

fahre mit 1/36el

Ende Zählschleife

WEnn wir jetzt in die zweite Bahn gehen, haben wir auch wieder 1/36 Zustellung in Z, so wie das oben korrigiert wurde, hätten wir die nicht.

Man muß sich das mit dem Programmieren wirklich nicht so schwer vorstellen. Das PRogrammieren ist das wenigste, das kann man sich schnell aneignen.

Bevor man da die Zeilen eintippt, muß man aber

DAS PROBLEM erkannt und richtig formuliert haben. Und zwar nicht in programmcode, sondern in ganz normaler Umgangssprache.

Das dann zu programmieren, ist wirklich das wenigste. Wenn man aber bei der Vorüberlegung einen Denkfehler drin hat, kann der Code nicht passen. Daher ist es unverzichtbar, ein frisch geschriebenes Programm erstmal auf Herz und Nieren zu testen. Ist bei meinen Programmen nicht der fall, weil die noch zu frisch sind, also der eine oder andere BUG kann immer mal drin sein.

Daher also ruhig mal auf den Compiler draufspielen und testen, jeder gefundene Fehler macht das PRogramm nur besser

Der Beitrag wurde von sharky bearbeitet: 26.01.2009, 11:19 Uhr

Sowas läßt mir ja keine Ruhe, wenn ich solche Zahlen sehe!

Wenn man pi mal etwas genauer zuweist, so z.B.:

double const pi= 3.141592653589793238462643383279502884197169399375105820974944592307816406286208
99 ;


Dann sieht die Anzeige auf dem Bildschirm für 10 Grad Schritte auch gleich viel netter aus:



/* Hardcopy vom Bildschirm für aufloesung=36 (10 Grad Schritte)


Radius=100.0000000 Winkel=0.000 X=100.0000000 Y=0.0000000 Z=0.0027778
Radius=99.9972222 Winkel=10.000 X=98.4780397 Y=17.3643354 Z=0.0055556
Radius=99.9944444 Winkel=20.000 X=93.9640416 Y=34.2001142 Z=0.0083333
Radius=99.9916667 Winkel=30.000 X=86.5953235 Y=49.9958333 Z=0.0111111
Radius=99.9888889 Winkel=40.000 X=76.5959327 Y=64.2716189 Z=0.0138889
Radius=99.9861111 Winkel=50.000 X=64.2698334 Y=76.5938048 Z=0.0166667
Radius=99.9833333 Winkel=60.000 X=49.9916667 Y=86.5881066 Z=0.0194444
Radius=99.9805556 Winkel=70.000 X=34.1953639 Y=93.9509903 Z=0.0222222
Radius=99.9777778 Winkel=80.000 X=17.3609589 Y=98.4588907 Z=0.0250000
Radius=99.9750000 Winkel=90.000 X=0.0000000 Y=99.9750000 Z=0.0277778
Radius=99.9722222 Winkel=100.000 X=-17.3599942 Y=98.4534195 Z=0.0305556
Radius=99.9694444 Winkel=110.000 X=-34.1915637 Y=93.9405492 Z=0.0333333
Radius=99.9666667 Winkel=120.000 X=-49.9833333 Y=86.5736729 Z=0.0361111
Radius=99.9638889 Winkel=130.000 X=-64.2555492 Y=76.5767816 Z=0.0388889
Radius=99.9611111 Winkel=140.000 X=-76.5746537 Y=64.2537637 Z=0.0416667
Radius=99.9583333 Winkel=150.000 X=-86.5664560 Y=49.9791667 Z=0.0444444
Radius=99.9555556 Winkel=160.000 X=-93.9274980 Y=34.1868134 Z=0.0472222
Radius=99.9527778 Winkel=170.000 X=-98.4342705 Y=17.3566177 Z=0.0500000
Radius=99.9500000 Winkel=180.000 X=-99.9500000 Y=0.0000000 Z=0.0527778
Radius=99.9472222 Winkel=190.000 X=-98.4287993 Y=-17.3556530 Z=0.0555556
Radius=99.9444444 Winkel=200.000 X=-93.9170569 Y=-34.1830132 Z=0.0583333
Radius=99.9416667 Winkel=210.000 X=-86.5520222 Y=-49.9708333 Z=0.0611111
Radius=99.9388889 Winkel=220.000 X=-76.5576305 Y=-64.2394795 Z=0.0638889
Radius=99.9361111 Winkel=230.000 X=-64.2376940 Y=-76.5555026 Z=0.0666667
Radius=99.9333333 Winkel=240.000 X=-49.9666667 Y=-86.5448054 Z=0.0694444
Radius=99.9305556 Winkel=250.000 X=-34.1782629 Y=-93.9040056 Z=0.0722222
Radius=99.9277778 Winkel=260.000 X=-17.3522765 Y=-98.4096503 Z=0.0750000
Radius=99.9250000 Winkel=270.000 X=-0.0000000 Y=-99.9250000 Z=0.0777778
Radius=99.9222222 Winkel=280.000 X=17.3513118 Y=-98.4041791 Z=0.0805556
Radius=99.9194444 Winkel=290.000 X=34.1744627 Y=-93.8935646 Z=0.0833333
Radius=99.9166667 Winkel=300.000 X=49.9583333 Y=-86.5303716 Z=0.0861111
Radius=99.9138889 Winkel=310.000 X=64.2234098 Y=-76.5384794 Z=0.0888889
Radius=99.9111111 Winkel=320.000 X=76.5363515 Y=-64.2216243 Z=0.0916667
Radius=99.9083333 Winkel=330.000 X=86.5231547 Y=-49.9541667 Z=0.0944444
Radius=99.9055556 Winkel=340.000 X=93.8805133 Y=-34.1697124 Z=0.0972222
Radius=99.9027778 Winkel=350.000 X=98.3850301 Y=-17.3479353 Z=0.1000000
Drücken Sie eine beliebige Taste . . .
*/


Wenn ich von 6 Nachkommastellen spreche, sollten die auch sauber sein!

Der Beitrag wurde von sharky bearbeitet: 26.01.2009, 12:05 Uhr

So, Programm wurde jetzt etwas bequemer gemacht. Speichert die Datensätze nunmehr in eine Datei "helix.tap", anstatt sie nur auf dem Bildschirm zu zeigen.

Wir sehen, in "Radius" kann da was nicht stimmen. Radius müßte 99.9000000 sein, zeigt aber einen krummen Wert.

Der Grund ist, daß radius in der Zählschleife zu spät vermindert wird, erst nach der Koordinatenberechnung. Damit hängt radius um einen hinterher, und daher die krumme Zahl.

Um das zu ändern, müssen wir die Zählschleife so umformen:

std::ofstream out ("helix.tap"); // eröffnet uns eine Datei
for (int k=0;k<aufloesung;k++)
{
radius=radius-delta_radius; <----------------------- vorher, nicht nachher!
y[k]=sin_grad(winkel)*radius; // Koordinatenberechnung
x[k]=cos_grad(winkel)*radius;
sprintf(buffer,"Radius=%1.8f Winkel=%1.8f X=%1.8f Y=%1.8f Z=%1.8f\n",radius, winkel, x[k],y[k],z[k]);
out << buffer << "\n";//schreibt Datensatz in Datei
winkel=winkel+winkelschritt;
}


Jetzt ist die Tabelle rund.

Ich habe als Dateianhang mal spaßeshalber die Berechnung für 2400 Helixpunkte (ein Durchgang) angefügt, weil die gerade noch mit 199KB so eben angehängt werden darf. Bei Bedarf kann man daraus auch G-Code machen, aber aus den oben beschriebenen Gründen macht das nicht wirklich Sinn.







Hier ist jetzt die korrigierte Tabelle nach der Umstellung dieser einen kleinen Programmzeile (so ist es oft):

Radius=99.99722222 Winkel=0.00000000 X=99.99722222 Y=0.00000000 Z=0.00277778

Radius=99.99444444 Winkel=10.00000000 X=98.47530415 Y=17.36385305 Z=0.00555556

Radius=99.99166667 Winkel=20.00000000 X=93.96143131 Y=34.19916416 Z=0.00833333

Radius=99.98888889 Winkel=30.00000000 X=86.59291787 Y=49.99444444 Z=0.01111111

Radius=99.98611111 Winkel=40.00000000 X=76.59380481 Y=64.26983336 Z=0.01388889

Radius=99.98333333 Winkel=50.00000000 X=64.26804784 Y=76.59167690 Z=0.01666667

Radius=99.98055556 Winkel=60.00000000 X=49.99027778 Y=86.58570100 Z=0.01944444

Radius=99.97777778 Winkel=70.00000000 X=34.19441388 Y=93.94838002 Z=0.02222222

Radius=99.97500000 Winkel=80.00000000 X=17.36047656 Y=98.45615511 Z=0.02500000

Radius=99.97222222 Winkel=90.00000000 X=0.00000000 Y=99.97222222 Z=0.02777778

Radius=99.96944444 Winkel=100.00000000 X=-17.35951185 Y=98.45068395 Z=0.03055556

Radius=99.96666667 Winkel=110.00000000 X=-34.19061366 Y=93.93793899 Z=0.03333333

Radius=99.96388889 Winkel=120.00000000 X=-49.98194444 Y=86.57126724 Z=0.03611111

Radius=99.96111111 Winkel=130.00000000 X=-64.25376367 Y=76.57465369 Z=0.03888889

Radius=99.95833333 Winkel=140.00000000 X=-76.57252579 Y=64.25197815 Z=0.04166667

Radius=99.95555556 Winkel=150.00000000 X=-86.56405036 Y=49.97777778 Z=0.04444444

Radius=99.95277778 Winkel=160.00000000 X=-93.92488770 Y=34.18586338 Z=0.04722222

Radius=99.95000000 Winkel=170.00000000 X=-98.43153491 Y=17.35613536 Z=0.05000000

Radius=99.94722222 Winkel=180.00000000 X=-99.94722222 Y=0.00000000 Z=0.05277778

Radius=99.94444444 Winkel=190.00000000 X=-98.42606376 Y=-17.35517065 Z=0.05555556

Radius=99.94166667 Winkel=200.00000000 X=-93.91444668 Y=-34.18206316 Z=0.05833333

Radius=99.93888889 Winkel=210.00000000 X=-86.54961660 Y=-49.96944444 Z=0.06111111

Radius=99.93611111 Winkel=220.00000000 X=-76.55550258 Y=-64.23769398 Z=0.06388889

Radius=99.93333333 Winkel=230.00000000 X=-64.23590846 Y=-76.55337468 Z=0.06666667

Radius=99.93055556 Winkel=240.00000000 X=-49.96527778 Y=-86.54239973 Z=0.06944444

Radius=99.92777778 Winkel=250.00000000 X=-34.17731288 Y=-93.90139539 Z=0.07222222

Radius=99.92500000 Winkel=260.00000000 X=-17.35179415 Y=-98.40691472 Z=0.07500000

Radius=99.92222222 Winkel=270.00000000 X=-0.00000000 Y=-99.92222222 Z=0.07777778

Radius=99.91944444 Winkel=280.00000000 X=17.35082944 Y=-98.40144357 Z=0.08055556

Radius=99.91666667 Winkel=290.00000000 X=34.17351265 Y=-93.89095436 Z=0.08333333

Radius=99.91388889 Winkel=300.00000000 X=49.95694444 Y=-86.52796597 Z=0.08611111

Radius=99.91111111 Winkel=310.00000000 X=64.22162429 Y=-76.53635147 Z=0.08888889

Radius=99.90833333 Winkel=320.00000000 X=76.53422357 Y=-64.21983877 Z=0.09166667

Radius=99.90555556 Winkel=330.00000000 X=86.52074909 Y=-49.95277778 Z=0.09444444

Radius=99.90277778 Winkel=340.00000000 X=93.87790307 Y=-34.16876237 Z=0.09722222

Radius=99.90000000 Winkel=350.00000000 X=98.38229453 Y=-17.34745295 Z=0.10000000

Und wo wir gerade dabei sind, noch einen Fehler gefunden.

Wir stehen zwar auf Null grad = 3 Uhr, wollen aber ja gleich auch eine Winkelzustellung. Das ist das Ding mit der ersten zusätzlichen Bahn, der Nullzustellung, wodurch wir am Anfang der bearbeitung, und nur da, einen zusätzlichen Datensatz brauchen.

Geht die Bearbeitung aber los, fängt die Helix an zu laufen und wir brauchen natürlich sowohl beim Radius als auch beim Winkel Zustelllungen <> Null. Wir ändern das wie mit dem Radius, holen den Winkel aus seinem stillen Winkel hervor und setzen ihn VOR die Koordinatenberechnung.

Man sieht übrigens, die eigentliche Berechnung dieser tausenden oder Millionen von Koordinaten findet in lediglich 3 Programmzeilen statt:


for (int k=0;k<aufloesung;k++) z[k]=(k+1)*delta_z;
y[k]=sin_grad(winkel)*radius;
x[k]=cos_grad(winkel)*radius;

DIESE korrigierte Version wäre nun vollständig zur STeuerung einer Maschine geeignet, die eine Helix fräsen soll:


Radius=99.99722222 Winkel=10.00000000 X=98.47803972 Y=17.36433541 Z=0.00277778

Radius=99.99444444 Winkel=20.00000000 X=93.96404156 Y=34.20011422 Z=0.00555556

Radius=99.99166667 Winkel=30.00000000 X=86.59532350 Y=49.99583333 Z=0.00833333

Radius=99.98888889 Winkel=40.00000000 X=76.59593271 Y=64.27161888 Z=0.01111111

Radius=99.98611111 Winkel=50.00000000 X=64.26983336 Y=76.59380481 Z=0.01388889

Radius=99.98333333 Winkel=60.00000000 X=49.99166667 Y=86.58810662 Z=0.01666667

Radius=99.98055556 Winkel=70.00000000 X=34.19536394 Y=93.95099028 Z=0.01944444

Radius=99.97777778 Winkel=80.00000000 X=17.36095892 Y=98.45889068 Z=0.02222222

Radius=99.97500000 Winkel=90.00000000 X=0.00000000 Y=99.97500000 Z=0.02500000

Radius=99.97222222 Winkel=100.00000000 X=-17.35999421 Y=98.45341953 Z=0.02777778

Radius=99.96944444 Winkel=110.00000000 X=-34.19156372 Y=93.94054925 Z=0.03055556

Radius=99.96666667 Winkel=120.00000000 X=-49.98333333 Y=86.57367286 Z=0.03333333

Radius=99.96388889 Winkel=130.00000000 X=-64.25554919 Y=76.57678160 Z=0.03611111

Radius=99.96111111 Winkel=140.00000000 X=-76.57465369 Y=64.25376367 Z=0.03888889

Radius=99.95833333 Winkel=150.00000000 X=-86.56645599 Y=49.97916667 Z=0.04166667

Radius=99.95555556 Winkel=160.00000000 X=-93.92749796 Y=34.18681344 Z=0.04444444

Radius=99.95277778 Winkel=170.00000000 X=-98.43427049 Y=17.35661771 Z=0.04722222

Radius=99.95000000 Winkel=180.00000000 X=-99.95000000 Y=0.00000000 Z=0.05000000

Radius=99.94722222 Winkel=190.00000000 X=-98.42879934 Y=-17.35565300 Z=0.05277778

Radius=99.94444444 Winkel=200.00000000 X=-93.91705693 Y=-34.18301321 Z=0.05555556

Radius=99.94166667 Winkel=210.00000000 X=-86.55202223 Y=-49.97083333 Z=0.05833333

Radius=99.93888889 Winkel=220.00000000 X=-76.55763048 Y=-64.23947950 Z=0.06111111

Radius=99.93611111 Winkel=230.00000000 X=-64.23769398 Y=-76.55550258 Z=0.06388889

Radius=99.93333333 Winkel=240.00000000 X=-49.96666667 Y=-86.54480535 Z=0.06666667

Radius=99.93055556 Winkel=250.00000000 X=-34.17826293 Y=-93.90400565 Z=0.06944444

Radius=99.92777778 Winkel=260.00000000 X=-17.35227651 Y=-98.40965030 Z=0.07222222

Radius=99.92500000 Winkel=270.00000000 X=-0.00000000 Y=-99.92500000 Z=0.07500000

Radius=99.92222222 Winkel=280.00000000 X=17.35131180 Y=-98.40417914 Z=0.07777778

Radius=99.91944444 Winkel=290.00000000 X=34.17446271 Y=-93.89356462 Z=0.08055556

Radius=99.91666667 Winkel=300.00000000 X=49.95833333 Y=-86.53037159 Z=0.08333333

Radius=99.91388889 Winkel=310.00000000 X=64.22340981 Y=-76.53847937 Z=0.08611111

Radius=99.91111111 Winkel=320.00000000 X=76.53635147 Y=-64.22162429 Z=0.08888889

Radius=99.90833333 Winkel=330.00000000 X=86.52315472 Y=-49.95416667 Z=0.09166667

Radius=99.90555556 Winkel=340.00000000 X=93.88051333 Y=-34.16971243 Z=0.09444444

Radius=99.90277778 Winkel=350.00000000 X=98.38503010 Y=-17.34793530 Z=0.09722222

Radius=99.90000000 Winkel=360.00000000 X=99.90000000 Y=-0.00000000 Z=0.10000000

Der Beitrag wurde von sharky bearbeitet: 26.01.2009, 12:52 Uhr

****************************************
********* Programmierung einer *************
****************************************
********** Doppelhelix ********************
****************************************

In dem vorangegangenen Beispiel haben wir eine einfache Helix programmiert, und wir haben gesehen, daß das mit ganz wenigen Programmzeilenn getan ist. Der Grund ist ein sehr mächtiges Werkzeug bei der Programmierung,

ITERATION

Iteration heißt, einen Vorgang beliebig oft zu wiederholen. Das ist deshalb ein sehr mächtiges Werkzeug, weil es schwierige Berechnungen in der Regel um eine bis mehrere mathematische Ebenen vereinfacht. Insbesondere bei statistischen Funktionen, die allesamt ohne Ausnahme sehr komplex zu programmieren sind, kann man sich auf diese Weise die mathematische Schwierigkeit durch Zerlegen in Einzelprozesse handlicher machen.

Um mal ein Beispiel zu nennen: Für die Berechnung von Primzahlen gibt es Formeln. Ich kenne sie nicht. Aber ich wüßte, wie ich mit dem PC die ersten 1000 Primzahlen errechnen würde. Dazu müßte man zwei Schleifen ineinander verschachteln, wo die äußere die Zahl ist, die es zu untersuchen gibt, und die Innere von 2 beginnend bis Hälfte dieser Zahl hochzählt, und die Bedinung prüft. Ist Division ohne Modulo erfüllt, kann es keine Primzahl sein. Das ist ein Fünfzeiler, der innerhalb Sekundenbruchteilen die ersten 1000 Primzahlen ausspucken würde.

Wir wollen beim nächsten Projekt mal ein klein bißchen anspruchsvoller werden, damit die Leute aufhören zu sagen: ja, aber das sind doch ganz simple Strukturen, wie sie in der Praxis nie vorkommen.

Ob das nachfolgende Objekt in der Praxis vorkommt, weiß ich nicht. Es geht aber ja auch immer darum, das Prinzip zu realiseren, nicht immer nur um das Einzelstück.

Dazu wollen wir eine Struktur berechnen, in der sich zwei Helices überlagern, nämlich eine Korkenzieherartige Struktur. Unser Korkenzieher soll erstens im Radius der Drahtwicklung kleiner werden, nämlich auf Null abnehmen, so daß am Ende die Spitze exakt in der Mittenachse der Helix steht, zweitens soll das Material, nennen wir es mal den Draht, aus dem die Wicklung ist, in der Stärke ebenfalls bis auf Null abnehmen, damit wir also eine schöne scharfe Spitze kriegen. Das so ein sich verjüngendes Ding als Korkenzieher nicht taugen würde, sei dahingestellt, aber würden wir nicht verjüngen, hätten wir nur eine Helix und eine Schraube, oben steht aber Doppelhelix, da müssen wir uns jetzt auch dran halten.

Um das nicht ganz so einfach werden zu lassen, fügen wir noch eine Bedingung ein. Statt eine z-konstante Verjüngung wie bei der einfachen Helix, wollen wir eine progressive Verjüngung. Das heißt, bei halber Höhe ist der radius nicht 50%, sondern >50%. Das soll sowohl für die Wicklung als auch für die Drahtstärke gelten.

Wir müssen für diese progressive Verjüngung noch eine passende mathematische Funktion aussuchen.

Nun, wie gehen wir das an? Als erstes brauchen wir passende Datenstrukturen, um die Daten speichern zu können. Wir haben es hier mit einer Innenhelix zu tun, die durch den Mittelpunkt des gedachten Drahtes läuft, und einer Satellitenhelix, die sich um die andere Helix herumwindet und der Außenkontur des Drahtes entspricht. Die Steigungen dieser beiden Helices sind natürlich höchst ungleich. Der Korkenzieher hat eine recht hohe Steigung, während der Satellit, das Fräswerkzeug, natürlich nur in kleinen Bahnen abräumen kann.

Die STeigung unseres Korkenziehers wollen wir festlegen bei D, und die Höhe mit 2D, um anschauliche Daten zu haben. Das heißt, wenn der Korkenzieher 2mal den Vollkreis abgefahren ist, ist die Spitze erreicht.

Die Steigung des Werkzeugs wollen wir erstmal auf einen nicht so kleinen Betrag festlegen, z.B. 0.5, damit wir im Anfang nicht so riesen Datenmengen produzieren.

Was die Auflösung betrifft, muß sie natürlich für beide gleich sein

Was wir dazu an Datenstrukturen benötigen, ist nicht viel. Wir brauchen für jede Helix eine indizierte STruktur für die Ablage von x,y,z. Damit ist es aber noch nicht getan. Denn wir können der Maschine nicht zwei x-Werte anbieten, sondern nur einen. Und das wird weder der eine noch der andere sein, sondern ein resultierender Wert, also benötigen wir noch ein drittes indiziertes Element für die resultierenden x,y,z.

Wir wollen mal die Grenzwerte betrachten:

Sind wir oben an der Spitze angekommen, hat die Innenhelix die Koordinaten 0.0, wenn wir das Offset bequemerweise auf die Mittelachse des Schraubenziehers legen. Die Koordinaten des Satelliten sind dann ebenfalls 0.0, weil er mit der Bearbeitung der Drahtkontur soweit fertig ist, daß er Mitte Drahtkontur steht, und die steht eben jetzt bei 0.0.

Unter 0.0 ist die physikalische Kontur zu verstehen, natürlich, die Spindel steht an einer anderen Stelle, welche wir bequemerweise in G90 sowieso mit Bahnkorrektur fahren. Und daß das Werkzeug hier kein Fingerfräser sein kann, sondern so ´ne Art Scheibenfräser, ist auch klar, für die Geometrie aber zunächst mal unwichtig.

Wenn wir am dicken Ende die Startbedingungen durchgehen, und der Korkenzieher bei 3 Uhr anfangen soll, gegenläufig zu 12 Uhr hin, dann ist der Mittelpunkt der Innenhelix (das ist die Mitte vom Draht) bei y=0 x=Ri (Ri=Radius Innenhelix). Der Satellit möge ebenfalls auf 3 Uhr beginnen, und stünde dann in seiner Welt bei y0 Rs (Rs=Radius Satellit). Da Ri und Rs an dieser Stelle noch identisch ist, liegt die Außenkante der Kontur bei 2xRi. Wäre Ri unten 20 mm, wär die Außenkante der Außenkontur also bei y0 x40.

Man ahnt hier schon, wie man zu den gesuchten resultierenden Werten gelangt: Wir müssen einfach nur das Offset der Innenhelix dem Satelliten zuschlagen. Das verhält sich ungefähr so, als würde man folgendermaßen vorgehen:

g90
Fahre Koordinate Innenhelix
g91
Fahre Koordinate Satellit

Der Satellit ist eine typische G91 Anwendung, der fährt seinen Stiefel runter und das absolute Offset interessiert ihn nicht.
Natürlich werden wir uns an den Vorschlag von Matthias halten und das G91 tunlichst vermeiden. Wenn ein Rechenfehler drin wäre, würden wir gerade bei frisch gebackenen Programmen denselben sofort auf der Steuerung erkennen, in G90. Das ist wirklich ein schlagendes Argument für G90. Ob jetzt eine vernünftige Steuerung wie Heidenhain sowas kann, weiß ich nicht. Meine kann es jedenfalls nicht und da hab ich in G91 schon so manche Überraschung erlebt.

Soweit zu dem Projekt, ich bin gerade nach Haus gekommen und fang man an zu programmieren. Ob das heute abend noch was wird, wird man sehen. Manches, was zunächst einfach erscheint, kann sich ja auch als komplizierter herausstellen wie gedacht.

Ich hab leider keine Möglichkeit, die von mir ersonnene Struktur grafisch darzustellen, muß mich da auf meine Vorstellungskraft verlassen.

Vielleicht kann ja jemand, der eine gute CAM hat, so ein ähnliches Objekt mal zur Anschauung reinstellen. Ich bin mir nämlich nicht sicher, bzgl. der Bearbeitung, ob so ein Korkenzieher nicht irgendwo tote Winkel hat, wo man mit dem Werkzeug je nachdem nicht hinkommt. Daher hab ich die Steigung hier erstmal recht hoch gewählt.

Der Beitrag wurde von sharky bearbeitet: 26.01.2009, 19:21 Uhr

Es geht hier den meisten (auch mir!) natürlich um möglichst schnelle Ergebnisse.


Was besseres gibt es ja gar nicht.

Aber vor den Erfolg haben die Götter den Schweiß gesetzt!

Ich hab ja die Hoffnung noch nicht aufgegeben, daß einer vom Forum, der Ahnung hat, wie Werkzeugmaschinen ticken, dann auch mal in die Programmierung einsteigt und man sich ergänzen kann. Zwei Leute schaffen mehr als einer, fünf mehr als zwei.

Der Code eines fertigen C-Programms ist zum Abgewöhnen, keine Frage. Da sind mehr Unklarheiten versammelt als würden sich die Pychoanalytiker dieser Welt, ach was sage ich, im Umkreis von 100 km zu einem Kongress treffen. Das liegt daran, daß man an einem fertigen Programm den Werdegang nicht mehr sieht. Es ist eben alles fertig und ausgefeilt, die dahinterstehende Logik ist dann nicht mehr so einfach erkennbar.

Daher möchte ich die Gelegenheit mal wahrnehmen, zu zeigen, wie ich (ich bin nicht repräsentativ, aber eine Möglichkeit unter vielen) so ein Projekt vorbereite, wie oben angekündigt, und das kommentieren. Ein Programm ist im Anfang noch übersichtlich.

Z. B. dieses hier, dessen erste Version (einfache Helix) wir ja oben schon gesehen haben.

Damit der Code nicht verhunzt wird, setze ich erstmal den Code rein, und dann nochmal eine Kopie vom Code, die ich dann zeilenweise erkläre.


#include <iostream>
#include <stdio.h>
#include <math.h>
#include <fstream>
#include <sstream>
#include <stdlib.h>
using namespace std;

double sin_grad(double winkel);
double cos_grad(double winkel);

double const pi= 3.141592653589793238462643383279502884197169399375105820974944592 ;

long const aufloesung = 1000;

struct koordinaten
{
double xi[aufloesung],yi[aufloesung],zi[aufloesung]; //i=Innenhelix, Korkenzieherwindung
double xs[aufloesung],ys[aufloesung],zx[aufloesung]; //s=Satellit, die Drahtstärke
double resx[aufloesung],resy[aufloesung],resz[aufloesung]; //res=die resultierenden Koordinaten
};

koordinaten kn[aufloesung];
koordinaten *p =kn;
void berechne_koordinaten_innen();
void berechne_koordinaten_satellit();
void berechne_endkoordinaten();
void speichere_endkoordinaten();
int main(void) // *********************************main
{
system("PAUSE");
return EXIT_SUCCESS;
} //*********************************************** end main


double sin_grad(double winkel)
{
double zahl;
zahl=sin(winkel*pi/180);
return(zahl);
}

double cos_grad(double winkel)
{
double zahl;
zahl=cos(winkel*pi/180);
return(zahl);
}

void berechne_koordinaten_innen()
{
}

void berechne_koordinaten_satellit()
{
}

void berechne_endkoordinaten()
{
}

void speichere_endkoordinaten()
{
char buffer[80];
std::ofstream out ("doppelhelix.tap");
out << buffer << "\n";
}



#include <iostream>
#include <stdio.h>
#include <math.h>
#include <fstream>
#include <sstream>
#include <stdlib.h>
using namespace std;

-> Für die Speicherung der Dateien mittels std::ofstream out braucht man erstaunlicherweise nicht fstream, sondern sstream. Warum das so ist, nicht fragen, einfach reinsetzen


double sin_grad(double winkel);
double cos_grad(double winkel);

-> das sind zwei alte Bekannte, die uns den ARCTAN=Bogenwinkel in Gradmaß umrechnen

double const pi= 3.141592653589793238462643383279502884197169399375105820974944592 ;

-> wir hängen in allem von pi ab. Immer liebevoll pflegen!


long const aufloesung=1000;

-> Jetzt folgt ein sehr guter Trick bei der Programmierung.
Würde man erstmal alles so in absoluten Zahlen setzen, wie man braucht, also 100, 500 oder sonstwas, käme man sehr ins Schleudern, wenn man das Programm ändern wollte. Dann müßte man alle diese Zahlen finden und ändern, und würde man eine davon übersehen, könnte sonstwas passieren.

Daher sehen wir an der OBERSTEN STELLE IM PROGRAMM GLOBAL schon mal die Globalen konstanten vor, wie z. B. auflösung, ungeachtet der Tatsache, daß diese sich natürlich auch ändern werden, AAAAAAAAAAABER: Wenn wir es so machen, müssen wir nur diese einzige Zahl ändern.

DENN:

Nachdem wir unsere erste Struktur erklärt haben, z. B. diese


struct koordinaten
{
double xi[aufloesung],yi[aufloesung],zi[aufloesung]; //i=Innenhelix, Korkenzieherwindung
double xs[aufloesung],ys[aufloesung],zx[aufloesung]; //s=Satellit, die Drahtstärke
double resx[aufloesung],resy[aufloesung],resz[aufloesung]; //res=die resultierenden Koordinaten
};

-> und mit kn die Variable dazu deklarieren, ist eben die Frage, wieviel Speicherplatz brauchen wir zu dieser Variable, und genau diese Frage beantworten wir nicht mit kn[500], sondern mit kn[aufloesung]. Das Programm nimmt das, weil wir aufloesung als KONSTANTE erklärt haben. Eine Konstante wird vom Compiler wie der Zahlenwert behandelt. Würden wir aber die Konstante ändern in 50000, würde die vom Compiler auch als Zahlenwert gehandelt. Daher also:

koordinaten kn[aufloesung];

koordinaten *p =kn;
-> Hier haben wir unseren alten Bekannten, uns3eren Pointer Peter, den wir jetzt mit p abkürzen, um kürzeren Code zu haben. Solche mnemotechnischen Tricks wie einen Pointer Peter zu nennen, ist gute Programmierpraxis, das prägt sich im K opf ein, daß *p dann eben Peter ist und nicht etwa pi.


void berechne_koordinaten_innen();
void berechne_koordinaten_satellit();
void berechne_endkoordinaten();
void speichere_endkoordinaten();

-> Hier sieht man, was in Planung ist. Wir wollen erst Koordinaten von der einen Helix berechnen, dann die nächste, dann die Werte abgleichen und in endkoordinaten umrechnen, und dann den ganzen Kram speichern. Das ist an dieser Stelle formal schon mal vorbereitet, wir müssen diese Funktionen nur noch mit Leben erfüllen


int main(void) // *********************************main
{
system("PAUSE");
return EXIT_SUCCESS;
} //*********************************************** end main

-> MAIN IMMER SCHLANK HALTEN! Bloß keine Zeile mehr als muß! MAIN ist unser BRAIN, da muß alles übersichtlich sein. WAS IMMER MAN IRGENDWIE ALS FUNKTION AUSGLIEDERN KANN, GEHÖRT NICHT IN MAIN! In Main wird nur aufgerufen.

Daß ich main nicht als main() erkläre, sondern als main(void), liegt daran, daß iich gelesen habe, main() führt zu langsamerem Code, weil zum ganz alten Ritche-C gehörig, der Ansi standard verlangt entweder Argumente, oder wenn kein Argument drin steht, eben einen Platzhalter, das ist (void) Ob das stimmt, weiß ich nicht, zur Vorsicht erkläre ich das eben so.

double sin_grad(double winkel)
{
double zahl;
zahl=sin(winkel*pi/180);
return(zahl);
}

double cos_grad(double winkel)
{
double zahl;
zahl=cos(winkel*pi/180);
return(zahl);
}

void berechne_koordinaten_innen()
{
}

void berechne_koordinaten_satellit()
{
}

void berechne_endkoordinaten()
{
}

void speichere_endkoordinaten()
{
char buffer[80];
std::ofstream out ("doppelhelix.tap");
out << buffer << "\n";
}

-> Wir sehen die leeren Hüllen unserer vordefinierten Funktionen. Diese schon jetzt als leere Hülle zu formulieren, ist sehr gut. Wir wissen dann, die Klammerungen passen, der Compiler hat nichts zu meckern und können dann, erst dann,

WENN DER GANZE DEKLARATIONSTEILS FORMAL IN ORDNUNG ISt,

mit dem Programmieren beginnen.

Deklarationen sind auch Programmierung! Sogar ein sehr wichtiger Teil davon. Wir prüfen das mit einem Compilerdurchlauf, ob der auch alles richtig verstanden hat (und nicht meckert), damit wir FORMAL AUF DER SICHEREN SEITE SIND!

Denn:

eine einzige falsch gesetzte Klammer kann das ganze Programm ruinieren.

Daher ist die absolute strenge Zeichensprache von C ein weiteres Highlight dieser wirklich sehr schönen Sprache.

Der Beitrag wurde von sharky bearbeitet: 26.01.2009, 21:11 Uhr

Hier ist übrigens eine ziemlich dicke Fehlformulierung drin:


struct koordinaten
{
double xi[aufloesung],yi[aufloesung],zi[aufloesung]; //i=Innenhelix, Korkenzieherwindung
double xs[aufloesung],ys[aufloesung],zx[aufloesung]; //s=Satellit, die Drahtstärke
double resx[aufloesung],resy[aufloesung],resz[aufloesung]; //res=die resultierenden Koordinaten
};


Es ist heute irgendwie nicht mein Tag, was man ja heute morgen schon gesehen hat, bei der Berechnung der Helix. Flüchtigkeitsfehler sind ein Zeichen, daß man seinen Kopf woanders hat.

Was hier geschieht in Verbindung mit


koordinaten kn[aufloesung];

ist folgendes:

Wir erklären ein indiziertes array wie kn(von 1000, z. B.), innerhalb des Arrays sind die Variablen aber auch als array (von 1000,z. B.) erklärt.

Was heißt das?

Wir könnten die Variablen mit der Schleifenvariable so ansprechen, das wollen wir ja auch:

kn[n].xi

Wir haben aber bei der Deklaration xi selbst als indiziertes Array erklärt, können xi so also nicht ansprechen sondern müßten sagen:

kn[n].xi[n]

Das wollten wir nicht. Das würde Sinn machen, wenn man zwei Schleifen ineinander verschachtelt, z.B. so:

for (int k=1; ...
for (int q=1;...

kn[k].xi[q] ...

Das ist aber nicht gewünscht und nicht erforderlich.

Wenn wir eine ineinandergeschachtelte Deklaration machen, passiert folgendes:

Wir halten für k[n] n-mal den Speicherplatz für die ganze Struktur vor, sagen wir 1000 mal.

Wenn aber innerhalb von k noch die Werte ebenfalls als array indiziert sind, z. B. xi[n], dann halten wir

1000*den Speicherplatz für die Struktur vor multipliziert mit dem Speicherplatz sämtlicher darin enthaltenen indizierten Arrays, also ebenfalls 1000, das heißt, 1 MIO Speicherplatz für xi[n] und alles, was darin sonst noch so so deklariert wurde.

Nachdem ich von heute morgen an aber nur noch unkonzentriert bin und unscharf programmiere, also das heute wirklich nicht mein Tag ist, werde ich mit der Programmierung für heute mal Schluß machen.

Es geht aber weiter, keine Frage. Ein Projekt ist schließlich nicht etwas, was man in kurzer Zeit so mal eben erledigen könnte.

Wenn ich mit meinen Beiträgen einige der Mitleser zum Programmieren animiert haben sollte, wird sich das im Laufe der Zeit ja vielleicht noch etwas weniger monoton gestalten, als es derzeit ist. Wobei monoton nicht als Kritik zu verstehen ist. Wäre ich in einem C-Forum, wäre da sicher mehr Dialog, nur diese Leute in den C-Foren, die würden bei der Erwähnung von g91 oder Zustellung oder sonstwas nur noch Bahnhof verstehen.

Also hier ist das schon richtig aufgehoben.

Es geht hier nur angelegentlich um C, worum es wirklich geht ist NC, die numerische Steuerung von Maschinen.



Gruß Sharky

Der Beitrag wurde von sharky bearbeitet: 26.01.2009, 21:43 Uhr

Bzw. manche Leute sind ja auch der Meinung, daß

NC=CNC

wie die bloß drauf kommen.

NC ist NC. Ob man dafür eine Rechenmaschine irgendwelcher Art hernimmt nimmt oder das auf einem Blatt Papier ausrechnet, das Ergebnis ist dasselbe.

Wofür der G-code 50.000 Zeilen braucht, das kann man mit einer einzigen Formel auf einem Blatt Papier in 1 Sekunde hinschreiben. Ich will damit nichts schlechtes über den G-Code sagen, sondern nur es gibt einen Konflikt bei dem Flug der gedanken zum fertigen werkstück. Diese zerschellen, wie Bismarck schon sagte, an den Hindernissen am Boden. Wozu auf jeden Fall die Schnittstelle an der Machine in erster Linie gehört. Diese Schnittstellen sind in der Profi Szene vielleicht gut, und abgesehen davon, daß das bessere der natürliche Feind des guten ist, in der Hobbyszene sind sie garantiert nicht gut, und noch weniger optimal. Da tut sich weniges, was zur Hoffnung Anlaß gibt. Allein daß Mach3 nicht als open Source verfügbar ist, heißt, daß alle von unseren Steuergeldern teuer subventionierten Universiäten in ganz Europa völlig versagt haben. Es gibt office als open source, es gibt Tabellenkalkulation als open source, und mich stört noch nichtmal, daß man für Mach3 eine Lizenzgebühr zahlen muß, mich stört, daß man das Produkt nicht an seine Erfordernisse anpassen kann.

Ja ich weiß, früher hatten die Leute mehr Zeit.

Heute schaffen sie in einem Bruchteil der Zeit unglaubliche Ergebnisse, und verdienen REAL weniger als ein Zimmermann im Mittelalter. Der Zimmermann im Mittelalter konnte sich Sa So freinehmen und etwas mit seiner Familie unternehmen, heute arbeitet die Frau im Supermarkt Samstag und der Mann macht Sonntagsschicht.

Ist eben die neue Zeit.

Damals waren die Leute zufrieden und glücklich, heute SCHAFFEN SIE WIE DIE AFFEN und haben trotzdem kein Geld in der Tasche. Wenn die 1000 Euro übrig haben, kommt die Heizkosten-Nachzahlung. Die Konzerne sind ja auch nicht blöde, die warten nur drauf.

Also was ich mache, ist NC.

NC=NUMERIC CONTROL.

Darum geht´s doch.

Wie man dahin gekommen ist, ist vom ERGEBNIS her doch eigentlich nebensächlich.

Der Beitrag wurde von sharky bearbeitet: 26.01.2009, 22:36 Uhr

Ich hab heut morgen mal ein bißchen herumgespielt.

Mein grosses Problem ist, ich hab kein Grafikprogramm und kann nicht sehen, was ich da programmiere, ich muß es mir vor dem geistigen Auge vorstellen.

Kein Grafikprogramm? Aber iwo denn!

Wir haben doch Mach3. Wenn man jetzt das, was man programmiert, mal eben in g-Code umwandelt, müßte doch die Steuerung ... oder nicht?

Sie tut das.

Im Dateianhang die Datei doppelhelix.tap (welche bis dato noch keine Doppelhelix ist, sondern eine einfache).

DAS IST LAUFFÄHIGER G-CODE, auf meiner Steuerung getestet. Das heißt, ihc kann jetzt auf meiner Steuerung perfekte Helices fahren.




Man sieht dort sehr schön vor Augen, wie sich eine wunderschöne Helix entwickelt.

Mit G1 Befehlen! Damit man die helices besser sieht, hab ich vorher einen Kreis drum gezeichnet.

Auflösung ist 360 Punkte für den Vollkreis. Macht 360 G-Befehle. Mehr als 500 kann ich auf der Demo-Version auf diesem PC nicht fahren, auf dem PC an der Maschine könnte ich auch Auflösung 5000 Punkte oder sowas fahren, mal probieren, da würde das dann schon wesentlich interessanter.

Das dazugehörige Programm, was den G-Code für zunächst eine Helix erzeugt, in der gegenwärtigen Version, folgt hier, das ist lauffähiger C-Code. Für andere Maße von der Helix braucht man nur die Parameter ändern.

Man sieht, es ist noch lange nicht fertig, aber was fertig ist, klappt 1A!


#include <iostream>
#include <stdio.h>
#include <math.h>
#include <fstream>
#include <sstream>
#include <stdlib.h>
using namespace std;


double const pi= 3.141592653589793238462643383279502884197169399375105820974944592 ;
long const aufloesung = 360;
double const radius_grosse_helix=60;
double const werkstueck_hoehe=radius_grosse_helix*4;

double const delta_winkel=360.0/aufloesung;
double const drahtstaerke=10.0;
double const delta_steigung=werkstueck_hoehe/aufloesung; // das wäre z-konstant



double sin_grad(double winkel);
double cos_grad(double winkel);



struct koordinaten
{
double xi,yi,zi; //i=Innenhelix, Korkenzieherwindung
double xs,ys,zs; //s=Satellit, die Drahtstärke
double resx,resy,resz; //res=die resultierenden Koordinaten
};

koordinaten kn[aufloesung];
koordinaten *p =kn;

void berechne_koordinaten_innen();
void berechne_koordinaten_satellit();
void berechne_endkoordinaten();
void speichere_endkoordinaten(koordinaten *p);


int main(void)
{
berechne_koordinaten_satellit();
speichere_endkoordinaten(p);

system("PAUSE");
return EXIT_SUCCESS;
}


double sin_grad(double winkel)
{
double zahl;
zahl=sin(winkel*pi/180);
return(zahl);
}

double cos_grad(double winkel)
{
double zahl;
zahl=cos(winkel*pi/180);
return(zahl);
}


void berechne_koordinaten_innen()
{
}

void berechne_koordinaten_satellit()
{
double winkel=0.0;
double radius=drahtstaerke/2;
double hoehe=0.0;
double delta_radius=drahtstaerke/aufloesung/4;
for (int k=0;k<aufloesung;k++)
{
winkel=winkel+delta_winkel;
radius=radius-delta_radius;
hoehe=hoehe+delta_steigung;
if (winkel>360.0)winkel=winkel-360.0;
kn[k].xs=sin_grad(winkel)*radius;
kn[k].ys=cos_grad(winkel)*radius;
kn[k].zs=hoehe;
printf("Winkel=%f Radius=%f XS=%f YS=%f \n",winkel,radius,kn[k].xs,kn[k].ys);
}

}

void berechne_endkoordinaten()
{
}

void speichere_endkoordinaten(koordinaten *p)
{
char buffer[80];
std::ofstream out ("doppelhelix.tap");
for (int k=1;k<aufloesung;k++)
{
sprintf(buffer,"G1 X%f Y%f Z%f\n",p->xs,p->ys,p->zs);
out << buffer ;
++p;
}
}

Moin,

ohne mich inhaltlich zu beteiligen: so sieht Deine Helix aus.

t.

Hallo!

Der satellit ist schon bei der Arbeit. Ich hab mal ein nettes kleines G-Code Programm angefügt, was 100 Helixbahnen darstellt ,mit jeweils 36 Kreispunkten in G1. Um zu sehen, was da läuft, reicht die Auflösung. Die Datei hat ca. 150 KB.

Zur MACH3 Steuerung:

Sie kann 3-D Anzeige! Ich hab das vorher nur nie bemerkt, weil ich fast alles in G91 programmiere. Gibt man ihr g90, kann sie es. Dazu muß man mit der Maus auf das farbige Achsenkreuz unten links im Monitor fassen und es verdrehen. Geht aber nur, wenn das Programm steht. Falls der Bildschirm nicht stimmt, muß man auf regenerate drücken.

Leider kann ich die Fräsbahnanzeige aber nicht speichern. Sie geht nur in Mach3.

Wer sich das Programm in 3D am Bildschirm mal ansehen will, kann sich dafür die kostenlose MACH3 Demo Version herunterladen. Falls die Demo-Version (begrenzt auf 500 Zeilen) das nicht macht, müßte man das Programm in der Länge mit dem Editor etwas verkürzen.

Ich hab mir für die nächsten Stunden vorgenommen, dem Satelliten beizubringen, daß er sich gefälligst um den Korkenzieher herumzuwickeln hat. Mal sehen ob´s klappt.

@nebbe

Danke für die Abbildung! Vielleicht bist du so nett, noch so das eine oder andere auch mal grafisch umzusetzen, du machst es wahrsscheinlich mit der gcode-Datei, vermute ich? Achtung bei der datei test.aktuell sind noch Programmkopf und Programmschluß angefügt, würde man wahrscheinlich vor dem Auswerten entfernen müssen.


Gruß Sharky

Der Beitrag wurde von sharky bearbeitet: 27.01.2009, 17:13 Uhr

<ALT GR> <DRUCK>
Dann irgendein Bildbearbeitungsprogramm öffnen, rechte Maus "Einfügen" und als JPEG abspeichern. Anschließend hier hochladen.

Gruß,

Clemens

cam-tool, du bist schon ein genie. Von so einer Tastenkombination hab ich im Leben noch nichts gehört.

Mein Satellit ist längst von der Anzeige verschwunden, hier sieht man, vor welchen Problemen ich derzeit stehe.

Es sind da noch einige Denkfehler bei der Programmierung auszuräumen.

Was man hier sieht ist, daß eine winkelkonstante Zustellung bei einem Korkenzieher und dem dazugehörigen Satelliten der falsche Algorithmus sind.

Ich stell das jetzt um auf z-konstant, muß dafür aber das ganze PRogramm modifizieren.

Der Beitrag wurde von sharky bearbeitet: 27.01.2009, 19:32 Uhr

Hmm, das sehe ich zwar grundsätzlich genauso, aber o.g. Tastenkombination kennt wirklich jede Sekretärin.

Ich hab das ganze Programm nochmal zurückversetzt in den Zustand von vor 4 Stunden.

Mir sind einige schwere Denkfehler unterlaufen. Der eine davon war, daß eine winkelkonstante Zustellung bei einem großen radius natürlich nicht zu einer bei einem kleinen Radius paßt, man muß das abgleichen, indem man die ganze Geometrie in Scheiben aufteilt, z. B. in Z. Dann findet man die korrespondierenden Punkte für den Offset-Zuschlag.

Ich bin also heute abend im Problem nicht viel weitergekommen, aber mit meinen Arbeitsmitteln sehr viel weiter, weil ich nämlich nun mit MACH3 eine 3D-Oberfläche entdeckt habe, und um die Programmierung in 3D zu kontrollieren, nur die Koordinaten in G-Code mit G1 Befehlen umwandeln muß. Das ist ein großer Schritt nach vorn. Und was ich nicht gedacht hätte, daß Mach3 auch große Datenmengen G-Code frißt und im voraus berechnen kann.

Langer Rede kurzer Sinn: ab heute abend kann ich in 3D sehen, was ich so programmtechnisch verbrochen habe. Das wird bei der weiteren Entwicklung von 3D-Programmen natürlich sehr mächtig helfen.

Derzeitiger Zustand also erstmal wieder der Satellit bei der Arbeit. Hier ist er. Das ist kein Zylinder, sondern eine ECHTE HELIX mit sehr geringer Verjüngung. Die Grafik zeigt uns den unteren Teil unseres Korkenziehers, allerdings noch ohne den Offsetversatz der zweiten Helix. Ist also nur eine einfache Helix, aber das wird schon noch.

Der Beitrag wurde von sharky bearbeitet: 27.01.2009, 21:46 Uhr

Man muß sich vorstellen:

Alles das, was Mach3 auf der Fräsbahnanzeige in der Lage ist anzuzeigen, kann man damit auch fräsen.

Es gilt herauszufinden, wieviel Datensätze frißt sie? Womöglich frißt sie unbeschränkt viele Datensätze, weil sie mit ziemlicher Sicherheit einen buffer hat und das möglicherweise, egal wie lang die Datei ist, stückchenweise einliest.

Was hieße das?

Wir könnten mit einer PC-Steuerung für 300 Euro echte 3D-Objekte fräsen mit G-Befehlen von 500.000 Zeilen (so mal dahingesagt, Vermutung).

Wir könnten das auf eine sehr unelegante Weise, indem wir die Steuerung mit G-Code totschmeissen. 500000 Zeilen sind zwar mächtig viel Zeug, aber das genaue Gegenteil von ELEGANT. Und 5 Mio wären besser, vom Ergebnis.

Eine andere sehr viel attraktivere Idee wäre, sozuagen Zyklen in C zu programmieren, so daß die Maschine in ECHTZEIT diese Zyklen ausführt. Ob das mit MACH3 möglich ist, weiß ich nicht, man wird da mal bei den Herstellern in Canada Kontakt aufnehmen müssen, um das abzuklären.

Seitdem CAM-tool dankenswerterweise diese geniale Tastenkombination verraten hat, können wir demnächst mit Grafiken kommunizieren, was die Kommunikation insbesondere bei dem vorliegenden Thema 3D sehr vereinfachen dürfte. Ein Bild sagt mehr als 1000 Worte.

Der Beitrag wurde von sharky bearbeitet: 27.01.2009, 23:10 Uhr

"Mach3 has a limit of 10,000,000 lines of Gcode even after licensing."
http://www.machsupport.com/downloads.php

Mit der Begrenzung wird man leben müssen.


Doppelhelix ist jetzt fertig, die Mach-Demo nimmt nicht mehr Daten als ein paar. daher sieht man hier nur einen Ausschnitt aus dem Unterteil des Korkenziehers, man kann aber Offset der großen Helix deutlich sehen

Der Beitrag wurde von sharky bearbeitet: 28.01.2009, 10:31 Uhr

Zur Programmierung:

Es geht einzig und allein um den passenden Algorithmus. Hat man den Algorithmus von der DENKLOGIK her gefunden, ist es dann auch egal, in welcher Programmiersprache man programmiert.

Natürlich, wenn man in C programmiert, erhält man fast ohne Mühe einen sehr schönen knappen Code, den man auch noch weiter verdichten könnte, aber von solchen extrem kompakten Stil halte ich gar nichts, weil dann zuverlässig die Übersicht verloreng geht. Von extrem kompakt zu unlesbar ist es nur ein kleiner Schritt.

Die gesamte Berechnung vollzieht sich in einer einzigen Funktion:

for (long q=0;q<zustellungen;q++) // rückt auf der großen Helix 1 vor
{
winkel_gr=winkel_gr+winkelschritt_grosse;if (winkel_gr>360.0)winkel_gr=winkel_gr -360.0;
radius_gr=radius_gr-verjuengung_grosse;

for (int k=0;k<anzahl_kreispunkte;k++) // rückt auf der kleinen Helix 1 vor
{
winkel_kl=winkel_kl+winkelschritt_kleine;if (winkel_kl>360.0)winkel_kl=winkel_kl-360.0;
hoehe_kl=hoehe_kl+hoehenschritt_kleine;
radius_kl=radius_kl-verjuengung_kleine;
kr[q].x[k]=sin_grad(winkel_kl)*radius_kl;
kr[q].y[k]=cos_grad(winkel_kl)*radius_kl;
kr[q].z[k]=hoehe_kl;
// Jetzt das XY Offset der grossen Helix zuschlagen, höhe bleibt!:
kr[q].x[k]=kr[q].x[k]+sin_grad(winkel_gr)*radius_gr;
kr[q].y[k]=kr[q].y[k]+cos_grad(winkel_gr)*radius_gr;
}
}
}

Das ist alles. Es sind zwei ineinander geschachtelte Schleifen. Das entspricht fast völlig exakt dem Problem. Und für die Daten haben wir eine zweidimensionale Tabelle, die Planetendaten in Reihe, die Satellitendaten in Zeilenrichtung. AUch das entspricht ziemlich exakt dem Problem.

Mit der Helix-Programmierung verfügen wir für unsere Werkzeugmaschine über ein sehr mächtiges Werkzeug.

DENN: mit der Helix definieren wir nicht nur die geometrische Form des Körpers, sondern haben zugleich die Fräsbahn für 3D-Projekte OHNE (!) Anfahrbögen. Das verkürzt die Bearbeitungszeit enorm und macht jedenfalls von der Theorie her eine sehr schöne, homogene Oberfläche.

Mit der Helix kann man alles mögliche erzeugen, z. B. um einen Kegel zu kreieren, setzt man die Verjüngung der Spirale größer, will man einen Zylinder, setzt man die Verjüngung auf 0. So einen Zylinder als Helix wäre z. B. eine typische SchruppBearbeitung mit Rampe.

Und so weiter. Wenn man erstmal die grundlegenden geometrischen Figuren gelöst hat, kommt man dann auch sehr schnell zu zusammengesetzten oder komplexeren Formen.

Der Beitrag wurde von sharky bearbeitet: 28.01.2009, 10:58 Uhr