Estlcam und die integrierte CNC Steuerung

Hallo Gunther,

in Version 8.303 leider das Gleiche 🙁

Hab leider auch keine Idee woran es liegen könnte.

Grüße Guido

Edit: Vielleicht nur ein Vorschauproblem, versuch mal in der Luft zu fräsen ob es doch Kreise werden.

Hallo Gunther,

ich habe die Datei mal in CAMotics (vormals OpenCAM) dargestellt - ein ganz brauchbares Open Source program - darin sind die Ersten Beiden Sacklöcher zumindest rund, die beiden Oberen sehen merkwürdig aus, da könnte die Darstellung von EstlCAm sogar hinkommen - wie sollte es denn eigentlich aussehen - 4 Bohrungen, oder doch Sacklöcher ?

Beste Grüße, Michael

Das sind Bohrungen von 2,2mm und 3,2mm mit einem 1mm Fräser.
NC-Corrector 4.0 zeig es so an, wie ich mir das dachte. Bei den 3,2mm löchern wird nahe der Mitte angesetzt und auf einer Spiralbahn nach Aussen gefräst, um in der Mitte keine Insel stehen zu lassen.

Ich habe den Verdacht, daß Estlcam und eventuell auch das CAMotics die Befehlen mit R-Angabe in der Form:
G03 X-36.6000 Y5.0000 R1.1000 F300
nicht richtig darstellen kann, sondern nur Befehle mit I- und J-Angaben richtig darstellt.

Ich werde die mal manuell ändern und testen.

Gruß Gunther

Oft treten die Probleme bei Kreisbögen >=180 Grad und der Ausgabe über den Radius auf. Hier ist die Ausgabe mit I und J deutlich besser.

Es handelt sich um Kreisbögen von genau 180°. Ich hab mal 2 Löcher auf I+J Ausgabe umgestell. Jetzt frisst Estlcam das.

Gruß Gunther

EDIT:

nun hab ich aber das Problem:
Das ULP "pcb-gcode" von Eagle giebt Kreisbögen immer mit dem Radius aus. Hab natürlich keine Lust das alles per Hand zu ändern.

Jemand dazu eine Idee?

Hilfreich wäre eine Teilung der Kreise in 3 oder 4 Bögen. Ich weiß aber nicht ob deine software dafür eine Option hat. Such mal nach maximaler Winkel für Kreisbögen...

Genau 90° Kreisbögen sind kein Problem, hab das mal schnell gemacht. In NC-Corrector sieht es gut aus.
Aber Estlcam macht wieder blödsin daraus.

Gruß Gunther

Du kannst es doch auch als Ausschnitt markieren, dann sollten die Probleme nicht auftreten.

Hallo,

Bögen und Kreise müssen im "I/J" Format mit relativen I/J Koordinaten ausgegeben werden.

Christian

Genau das hatte ich nach meinen Versuchen auch schon vermutet. Danke für die Bestätigung.

Jetzt bleibt das Problem mit der UPL für Eagle, diese giebt Kreisbögen leider nur im XYR-Format aus.

An alle Eagle-Nutzer:
- Wer kennt sich mit ULP-Programierung aus?
- Und kann eventuell das pcb-gcode entsprechend ändern.

Gruß Gunther

Disclaimer - Gleich eines vorweg - alle Gedanken zu dem Thema, die ich hier in irgendeiner Form zum Besten gebe, sind darauf ausgerichtet einen Denk- und Diskussionsprozess anzuregen, der letztendlich dazu führen kann, dass die Funktion von irgendjemandem realisiert wird --> also nicht zwangsläufig von mir ! (sic)

So und jetzt das was ich herausgefunden habe..
Nach etwas Recherche habe ich nun mehr Übersicht über die ULP Programmierung und ganz speziell über das pcb-gcode.ulp bekommen. ULP ist eine dem Standard C sehr ähnliche Scriptsprache mit speziellen Funktionen, die die Interna von Eagle bedienen - diese Scripts werden von Eagle während der Laufzeit interpretiert und ausgeführt. D.h. man kann sie einfach mit einem vernünftigen Code Editor (Notepad++ z.B.) schreiben, ändern und dann in das ULP Verzeichnis von Eagle ablegen.

Durch die recht Gute Dokumentation konnte ich das pcb-gcode.ulp und die zughörigen Files zügig überschauen und die relevante Stelle im G-Code Generator finden. Da ich aber Eagle nicht verwende und relativer Neuling in der g-code Programmierung bin, ist mir noch nicht genau klar, welcher mathematischer Weg hier erforderlich ist um das Problem zu lösen. Aber das kann sicherlich jemand hier beschreiben.

Mein Erstes Verständnis geht von einer Koordinatentransformation vom Kartesischen in das Polarkoordinatensystem aus - falls das richtig ist, müsste mann noch wissen, welche Parameter in welcher g-code Variablen aktuell geliefert werden und wie das nach der Transformation aussehen soll.

Wenn der Weg klar beschrieben ist, müsste jemand die Codierung übernehmen - und jemand mit Eagle Installation müsste sich bereit erklären Tests durchzuführen um die korrekte Funktion zu überprüfen und Feedback liefern.

Im Anhang findet sich der Ausschnitt aus dem pcb-gcode.ulp der sich mit dem Thema ARC/CIRCLE G-code Generierung beschäftigt.
(Da das anhängen einer Textdatei mit der Endung C hier nicht funktioniert hab ich den Ausschnitt hier eingefügt. (s.u.) Dabei hat leider die saubere Formatierung gelitten...

Beste Grüße, Michael

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

//
// "Draw" on the output device, i.e. the gcode file.
//
// Params:
// x1,y1 Start of the line.
// x2,y2 End of the line.
// state The state of the line being drawn, start, continue, etc.
// z_down_or_radius Z depth or radius of arc
// fr_xy XY feed rate
// fr_z Z feed rate
// Returns:
// none
// Changes:
// m_lines
// m_arc_begin_x
// m_arc_begin_y
// m_arc_radius
//
real m_arc_begin_x;
real m_arc_begin_y;
real m_arc_radius;
int pair_count = 0;
int MAX_COORDS_PER_LINE = 4;
void device_draw(int x1, int y1, int x2, int y2, int state, real z_down_or_radius, real fr_xy, real fr_z)
{
real rx1, ry1, rx2, ry2;

string str;

rx1 = scale_x(x1);
ry1 = scale_y(y1);
rx2 = scale_x(x2);
ry2 = scale_y(y2);
save_extents(rx1, ry1);
save_extents(rx2, ry2);

// Output g-code based on the current state.
switch(state) {

// Start of a new line.
case ST_START_LINE:
user_track_begin(rx1, ry1, rx2, ry2);

m_lines += coords(rx1, ry1, rx2, ry2);

rz(DEFAULT_Z_UP);
rxy(rx1, ry1);
fzr(z_down_or_radius, fr_z);
fxyr(rx2, ry2, fr_xy);
pair_count = 0;
break;

// A fill line.
case ST_FILL:
Fatal("Programmer Error", "The Fill functions are no longer supported.");
break;

// Continue a line.
// End a line.
case ST_CONTINUE_LINE:
user_track_continue(rx1, ry1, rx2, ry2);

m_lines += coords(rx1, ry1, rx2, ry2);

if (COMPACT_GCODE == YES) {
if (pair_count == 0) {
fxy(rx2, ry2);
}
else {
xy(rx2, ry2);
}

pair_count++;
}
else {
fxy(rx2, ry2);
}
break;

case ST_END_LINE:
user_track_end(rx1, ry1, rx2, ry2);

m_lines += coords(rx1, ry1, rx2, ry2);

if (COMPACT_GCODE == YES) {
xy(rx2, ry2);
pair_count = 0;
}
else {
fxy(rx2, ry2);
}
break;

// Drill a hole.
// todo is this valid?
case ST_DRILL:
printf("cause an error if used %d");
// printf("drill (%f, %f)n", rx2, ry2);
break;

// Create an arc.
case ST_ARC_BEGIN:
user_arc_begin(rx1, ry1, rx2, ry2);
m_arc_begin_x = rx1;
m_arc_begin_y = ry1;
m_arc_radius = internals_to_user(z_down_or_radius);
break;

// Finish an arc.
case ST_ARC_END:
user_arc_end(rx1, ry1, rx2, ry2);
real cx = rx2;
real cy = ry2;
real end_x = rx1;
real end_y = ry1;

rz(DEFAULT_Z_UP);
rxy(end_x, end_y);
fzr(z_down_or_radius, FEED_RATE_MILL_Z);

if (g_side == TOP || MIRROR_BOTTOM == YES) {
out(frrrr(ARC_CLOCK, m_arc_begin_x, m_arc_begin_y, m_arc_radius, fr_xy));
}
else {
out(frrrr(ARC_CCLOCK, m_arc_begin_x, m_arc_begin_y, m_arc_radius, fr_xy));
}
break;

////////// mlmSolutions 5 Feb 14

case ST_ARC:
if (m_z_up){
rz(DEFAULT_Z_UP);
rxy(rx1, ry1);
fzr(z_down_or_radius, fr_z);
}
if (((g_side == TOP) && m_cw) || ((g_side != TOP) && !m_cw)) str = ARC_CLOCK; else str = ARC_CCLOCK;
out(frrrr(str, rx2, ry2, internals_to_user(m_rad), fr_xy));
break;

//////////
}
// switch(state)
}
// device_draw

Ja diese Stelle hab ih auch in etwa im Auge nur will das ULP einfach nicht das richtige ausgeben.

Ich hab ein kleines Testprogramm geschieben, dort funktioniert es.

Ansonsten... um den Thread hier nicht vollzumüllen... weiter per PN

Gruß Gunther

Noch etwas Müll, vorerst hierzu mein Letzter - versprochen 😉
also grundsätzlich brauchts hier keinen Programmierer, das kannst Du ja ganz gut - sondern jemand der das hervorragende (englische) Manual von pcb-gcode gründlich durchliest -
- dann kommt man auf das Kapitel 4. Customizing
- und weiter ganz speziell auf das folgende Kapitel 4.4 User g-code

dort findet man heraus, dass das pcb-gcode.ulp unterschiedliche Profile verwendet
- das sind die .pp Dateien im Ordner profiles

dann schaut man malbeispielsweise in die mach.pp - und sieht ...
- pcb-code kann sehr wohl in I J Parametern ausgeben
- man muss es ihm nur über die Profildatei mitteilen und beim setup in der g-code-setup.ulp die Richtige profildatei wählen.

Die setup datei z.B. estlcam.pp kann man durch kopieren einer bestehenden .pp Datei in der die I J Parameter verwendet werden erzeugen
- und alles weitere an die Ausgabesteuerung anpassen - sehr flexibel gemacht
- Diese estlcam.pp wird dann über die pcb-gcode-defaults.h kopiert und damit in pcb-gcode zur Grundeinstellung.

Beste Grüsse, Michael

Hast PN!

Gruß Gunther

Hallo,
ich wollte mal Estlcam mit dem Arduino Uno testen.
Habe die Demo eladen...Arduino Packet ebenfalls.
Arduino ist ein China Teil, habe es mit einem Testprogem von der Arduino ide programmiert und es läuft.
Jedoch will es nach programmieren in estlcam keine Verbindung aufbauen....immer wieder "kann keine Verbindung zur Steuerung aufbauen".
Wie gesagt...wenn ich über die Arduino Software programme aufspiele funktionieren diese...nur bei estlcam gehts nicht....
Kann es an der Demo liegen?

Vielleicht weiß jemand einen Tip?

Gruß

Holger