Canvas.Arc Problem

[Uwe Raabe]

Ja, das sind die üblichen Probleme, mit denen man sich beim Zeichnen von Bögen herumärgern muss. Ursache sind hier die Fälle, bei denen nach der Umrechnung der Start- und Endkoordinaten von Double nach Integer die Ergebnisse identisch sind. Eigentlich kann man da keinen Bogen malen, aber wenn man es dennoch versucht, macht Windows einen Vollkreis daraus. Bei Linien fällt das halt nicht auf.

Es bleibt also keine Wahl: Man muss erst die Umrechnung machen, dann jeweils die X- und Y-Werte auf Gleichheit prüfen und - falls beide gleich - den Arc-Befehl überspringen.

[DaCoda]

@Uwe Raabe: Vielen Dank für deine Mühe und Zeit, die du für mich "geopfert" hast!

Ich habe es jetzt erst einmal so weit "fertig". Die Arcs einfach auslassen ist keine schöne Alternative.
Deshalb überlege ich nun, ob ich eventuell mit 3D-Zeichnen direct mit den Gleitkomma-Werten besser beraten bin.
Nur muss ich mir zuerst erst mal klar amchen, womit ich das dann mache (OpenGL, DirectX oder Sonstwas).

FMX wäre eventuell auch brauchbar, aber mein Projekt ist ja VCL und es wäre sehr viel Aufwand alles neu zu machen wegen FMX.

Im Moment muss ich wohl erst einmal viel googlen und schauen was ein guter Ansatz sein könnte...

Auf jeden Fall vielen Dank an Euch für die Hilfe und Tips

[Uwe Raabe]

Zitat von DaCoda:

Die Arcs einfach auslassen ist keine schöne Alternative.

Du sollst ja nur die auslassen, die bei der aktuellen Auflösung gar nicht zu sehen wären (konsequenterweise übrigens auch bei Linien). Wenn bei einem Bogen oder einer Linie die Bildschirmkoordinaten für den Start- und Endpunkt identisch sind, dann kann man die halt nicht darstellen (allenfalls als Punkt, aber das ist nur selten sinnvoll). Auch hat der Endpunkt des vorigen Elements und der Startpunkt des folgenden Element ja auch genau diese Koordinaten. Insofern verlierst du ja nichts - die Kontur weist dabei keine Lücken auf.

Das Problem geht übrigens mit 3D-Grafikroutinen bei OpenGL oder DirectX nicht weg. Es gibt Frameworks die das selbst abfangen, aber am Ende machen die auch genau das: die lassen solche Elemente einfach weg.

[DaCoda]

Ich hatte das so probiert, ich denke aber das ist auch nicht richtig gedacht von mir:

Code:

procedure TGCodeRenderer.DrawArc(CX, CY, Radius, StartAngle, EndAngle: Double; Clockwise: Boolean; Color: TColor);
var
  StartX, StartY, EndX, EndY: Double;
  ArcRect: TRect;
begin
  StartX := CX + Radius * Cos(StartAngle);
  StartY := CY + Radius * Sin(StartAngle);
  EndX := CX + Radius * Cos(EndAngle);
  EndY := CY + Radius * Sin(EndAngle);

  (* DIESEN TEIL HATTE ICH MAL GETESTET, IST ABER SICHER AUCH WIEDER FALSCH *)

  if (Round(StartX * FScale) = Round(EndX * FScale)) or (Round(StartY * FScale) = Round(EndY * FScale)) then begin
    FCurrentX := EndX;
    FCurrentY := EndY;
    Exit;
  end;
  *)

  (**************************************************************************)

  ArcRect := Rect(
    Round((CX - Radius) * FScale),
    Round((CY - Radius) * FScale),
    Round((CX + Radius) * FScale),
    Round((CY + Radius) * FScale)
    );

  FCanvas.Pen.Color := Color;

  if Clockwise then begin
    FCanvas.Arc(ArcRect.Left, Round(AdjustY(ArcRect.Top)), Round(ArcRect.Right), Round(AdjustY(ArcRect.Bottom)), Round(EndX * FScale), Round(AdjustY(EndY * FScale)), Round(StartX * FScale), Round(AdjustY(StartY * FScale)));
  end else begin
    FCanvas.Arc(ArcRect.Left, Round(AdjustY(ArcRect.Top)), Round(ArcRect.Right), Round(AdjustY(ArcRect.Bottom)), Round(StartX * FScale), Round(AdjustY(StartY * FScale)), Round(EndX * FScale), Round(AdjustY(EndY * FScale)));
  end;

  FCurrentX := EndX;
  FCurrentY := EndY;
end;

[Uwe Raabe]

Die Berechnung der Winkel aus Start- und Endpunkt zusammen mit der Rückberechnung von Start- und Endpunkt innerhalb DrawArc ist generell schon etwas ungeschickt.

Ich hänge mal meine Version der Unit an. Vielleicht hilft dir das ja auf den rechten Weg

[DaCoda]

Soooo, nun ist es so wie ich es wollte. Und es funktioniert dank Uwe sehr gut.
Es waren noch ein paar Änderungen nötig und Fehler bei Pos(...) ausgemerzt...

Vielen Dank!

[Maekkelrajter]

Falls du mit deinem Programm nicht nur dieses eine NC-Programm (Testdatei_002.nc, wirklich putzig!) oder andere Programme aus derselben Quelle darstellen willst, solltest du das Design des 'Parsers' überdenken. Der zerlegt einen 'Block' (Programmzeile) in die einzelnen 'Worte', mit dem Leerzeichen (ASCII #32) als Trennzeichen. Leerzeichen oder Tabulatoren zwischen den Worten sind aber nach DIN 66025 optional und dienen in erster Linie der besseren Lesbarkeit des (ASCII-) NC-Programmtextes für den Programmierer oder Bediener. Die Maschinensteuerung ignoriert Leerzeichen i. d. R.
'G03 X16.4034 Y19.6197 I16.2573 J29.8664 F600' hat dieselbe Funktion wie 'G03X16.4034Y19.6197I16.2573J29.8664F600'.
Ich weiß, wovon ich rede. Ich habe mich beruflich jahrelang mit CNC-Programmierung beschäftigt und habe selbst Programme zur grafischen Darstellung von CNC- Bohr- und Fräsprogrammen für Steuerungen von Excellon (Format 1 + 2) und Sieb & Meyer (Format 3000) mit Delphi 4 entwickelt. Das ist allerdings über 20 Jahre her.

Gruß LP

[DaCoda]

@Maekkelrajter:

Der Parser ist in diesem Testprogramm quick and dirty. Es ging um die Arc-Funktion (G02/G03).
Im nächsten Schritt wird ein Parser kommen, der auch eine Prüfung des G-Codes durchführt.

Ich bin allerdings CNC-Anfänger und muss noch einiges lernen...

Vielen Dank für deine Anmerkung, ich werde versuchen das mit zu berücksichtigen.