---

Hallo,

bei mir tritt beim Ausführen einer LISP-Routine (in der auch viel mit dem BKS gespielt wird) häufig ein Fall ein, den ich eigentlich für unmöglich gehalten hatte:
Das Fadenkreuz liegt in der Ebene des WKS (welches in diesem Fall eine isometrische Ansicht repräsentiert), während das BKS weiterhin eine "Draufsicht" beschreibt.
Eine weitere Einfügung eines Blocks erfolgt danach in der isometrischen Ebene des Fadenkreuzes.
Eigentlich dachte ich, dass eine solche Unstimmigkeit zwischen BKS-Symbol und Fadenkreuz gar nicht auftreten kann. Weiss jemand, woher dieses Verhalten kommen könnte?

Gruss,
Dirk Mehnert

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

---

Hi

wie ist denn der Wert für snapang?
sollte 0,0 sein.

------------------
Gruß
CADwiesel

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

---

Hi,

vielen Dank für die schnelle Antwort. Leider liegt es aber nicht daran (hätte mich auch gewundert, denn snapang wird in der Routine nicht verändert).
Es ist vielmehr wirklich so, dass das Fadenkreuz nicht nur um 45° gedreht, sondern auch um 60° nach hinten gekippt ist - isometrisch eben!

Gruss,
Dirk

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

---

Hi,

ich bin da selbst auf eine Antwort gestossen:
Das ganze passiert nur in AC2000, wenn man mit AC12 erstellte Blöcke einfügt; und dann aber auch nur wenn zur Zeit der Einfügung das BKS nicht identisch mit dem WKS ist.
Dann wird nämlich der Block in Richtung des BKS eingefügt, das Koordinatenkreuz legt sich dann aber leider automatisch in die Ebene des WKS (nachdem regeneriert wurde), ohne das BKS mitzunehmen!

Abhilfe: Die AC12-Zeichnungen zuerst z.B. im AC13-Format speichern.

Dirk

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

---

Hallo Dirk,

hatten die Blöcke denn in R12 grundsätzlich eine andere Definition als in den Folgeversionen?
Ist bei mir schon ein bischen her, seit ich damit gearbeitet habe.
Ich hab' schon erlebt, daß ich bei einem Lisp-Programm, das Blöcke automatisch drehen und verschieben sollte, eigentlich ohne Grund dauernd die Koordinaten mit 'trans' umrechnen mußte. Das war aber schon in R13. Könnte aber sein, daß einige der Blöcke noch mit R12 erstellt wurden. Hab' mich damals schon böse gewundert.

Gruß Torsten

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

---

Na da hätten wir ja lange Raten können.
Gut das Du den Fehler gefunden hast

------------------
Gruß
CADwiesel

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

---

Hallo Thomas,

was meinst Du mit "Definition" der R12-Dateien?
Die R13-Zeichnungen sind gegenüber denen der 12er Version ca. 6 mal grösser, wenn sie mit AC2000 konvertiert werden.
Welche Infos da noch zusätzlich gespeichert werden weiss ich nicht. Möglicherwewise fehlt AC2000 da eine viewport Information oder ähnliches, sa dass dieses merkwürdige Verhalten zustande kommt.

Gruss,
Dirk

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

---

Hallo Dirk,

nein ich meinte eigentlich, ob in R12 die DXF-Gruppencodes bei den
Blöcken noch anders definiert wurden.
Bei R14 z.B. wird bei einer Blockerstellung das gerade gültige BKS
zum WKS für alle Elemente des Blocks. (Hört sich schon irgendwie merkwürdig an, oder?). Vielleicht war unter R12 diese Regel noch anders, und wenn Du jetzt den Block einfügst, erkennt die neuere Version vielleicht nicht mehr die Richtung des R12-Block-WKS.

Gruß Torsten

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

---

Hallo Thorsten,

das wäre eine plausible Erklärung für das Verhalten. Ich habe das jedoch noch nicht nachgeprüft. Wenn ich dazu komme werde ich das Ergebnis natürlich sofort publizieren.

Gruss,
Dirk

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