---

Elektro-Symbolerkennung-1.jpg Elektro-Symbolerkennung-2.jpg

Hallo, beim Stöbern und Aufräumen bin ich auf ein Programm gestoßen, das ich vor Jahren mal für einen Kunden erstellt habe, bei dem ich aber die Rechte behalten habe. Vielleicht besteht auch bei anderen Anwendern Bedarf für sowas. Ich habe diesen Beitrag bewusst nicht unter dem Thema Elektrotechnik eingestellt, weil es nicht die Elektrotechnik-Anwendungen betrifft, sondern die Auswertung von mit solchen Applikationen erstellten DWGs durch reines AutoCAD.

Es geht um DWGs mit Elektrosymbolen. Manche Programme erstellen diese Symbole auf eine Weise, die die Auswertung beispielsweise durch Elektrounternehmen verhindern soll. Da sind die Symbole dann jeweils als Einzelblock gespeichert, mit einem Namen, der keinerlei Rückschlüsse auf den Inhalt zulässt, auf aussagelosen Layern, ohne XDATA für Auswertungen, und alle mit Blockeinfügepunkt 0,0,0. Und um es auch wirklich schwer zu machen, sind die Blöcke mit den Elektrosymbolen dann auch noch leicht unterschiedlich gezeichnet, mit unterschiedlich langen Linien, unterschiedlichen Radien, unterschiedlichen Winkeln zwischen Linien im Block uswusf..

Hier ein Beispiel für die Ausgabe auf Befehl: LISTE eines Blocks, der einen Schalter darstellt:
---------- Insert of Block ----------------------------------------
                  Handle:  EFFF
          Current space:  Model
                  Layer:  XR$2$E-Elektrotechnik
                  Color:  BYLAYER
                Linetype:  AUSGEZOGEN
              Block name:  COMPLEXOBJECT_746
            Description: 
        Insertion point:  X=  0  Y=  0  Z=  0
          X scale factor:  1
          Y scale factor:  1
          Z scale factor:  1
          Rotation angle:  0

Mir fällt als einziger Grund dafür, die DWGs so unbrauchbar zu machen, nur der Wunsch der Programmierer ein, die Elektrobetriebe, die das z.B. für Angebotserstellung auswerten müssen, zum Kauf der teuren Anwendungen zu motivieren. Entweder setzt der Betrieb einen Lehrling an die DWG, der in wochenlanger Kleinarbeit die Symbole in einer DWG händisch zählt, oder man kauft das Programm ...

Mein Kunde bekam im Rahmen von Ausschreibungen solche auf die eine oder andere Weise nutzlos gemachten DWGs, manchmal sogar in einer DWG von verschiedenen Anwendungen gemischt, und hätte deshalb gleich mehrere Elektrotechnik-Anwendungen kaufen müssen. Er hat deshalb ein Programm bei mir in Auftrag gegeben, dass diese Symbolerkennung automatisch ausführt, und das dann die Daten in einer von Datenbanken oder Excel lesbaren Form ausgibt. Die beiden JPGs in der Anlage zeigen das.

Der Anwender kann dem Programm auch die Erkennung von Symbolen beibringen, die es noch nicht kennt, und diese werden dann bei späteren Erkennungsläufen in anderen DWGs ebenfalls mit berücksichtigt. Das Programm ist also lernfähig. Die erkannten Symbole werden standardmäßig auf einen passenden Layer verschoben (je nachdem z.B. "SCHALTER" oder "LEUCHTE" usw), und können auf Wunsch auch durch eigene Blocksymbole ersetzt werden, wobei der Einfügepunkt dann auch korrigiert wird, so dass auch die Zuordnung zu Gebäuden und Räumen möglich ist. Und natürlich kann man einen ganzen Satz DWGs im Batchbetrieb automatisch durch die Symbolerkennung jagen, und automatisch für jede DWG die Auswertung einzeln ausgeben.

Ich könnte mir vostellen, dass auch andere Anwender dieses Programm gut gebrauchen könnten. Gibt es einen Markt dafür? Welchen Preis würden Anwender wohl dafür bezahlen wollen?

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

---

Hi,
dafür gibt es einen Markt, in der Vergangenheit hat man inkl. dir darüber auch schon mal geschrieben.
Der Markt wird aber immer kleiner: Früher gab es nur "Zusatzprogramme" und heutzutage haben Bricscad
und selbst AutoCAD Funktionen, welche für derartige Aufgaben eine Hilfe darstellen.

Aber: Besser gewinnt immer - auch heute noch.

Geld: Schwierig
49-499€ vermute ich, wobei es viel viel mehr Wert hat, wenn man es denn benötigt.

Aktuell wichtigste Frage: Wie weit ist das Teil von Vorteil, gegenüber ACAD oder Bricscad native Funktionen!?
Das müßte man zunächst testen, jeder für sich.

Wenn ich mich recht entsinne, dann war die einzige mir bekannte (aber ungetestete) "Abo-Software" bei 70€ im Jahr.

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

---

aaa-neuerTest.dwg

Zitat:

---

Original erstellt von cadffm:
Aktuell wichtigste Frage: Wie weit ist das Teil von Vorteil, gegenüber ACAD oder Bricscad native Funktionen!?
Das müßte man zunächst testen, jeder für sich.

---

Danke für die Antwort. Mit nativen AutoCAD/BricsCAD Fuktionen ist das nicht lösbar. Mein Kunde hatte damals auch schon bei zwei anderen AutoCAD-Programmierern nachgefragt, bevor er zu mir kam, und beide hatten ihm mitgeteilt, dass sie das Problem für unlösbar halten. Es dann doch gelöst zu haben, hat meinem Ego ganz ungemein geschmeichelt :-)

Die Blockreferenzen der Elektrosymbole werden in diesen DWGs - vorsätzlich! - wirklich extrem unbrauchbar gemacht. Eine Beispiel-DWG lege ich mal bei.

Die Frage ist halt, wie viele Anwender das brauchen könnten. Das Programm allgemein verkaufsfähig zu machen, Handbuch zu schreiben uswusf wäre schon noch einiger Aufwand, und ich kenne die Elektrobranche gar nicht.

Aber klar: wenn man es dann braucht, dann zahlt man fast jeden Preis dafür. Mein Kunde war damals extrem unter Druck, um ein Angebot für die Elektroplanung in einem Bürohochhaus rechtzeitig abgeben zu können, und hat das deshalb als Einzelauftrag an mich gegeben und schon etliche tausend Euro bezahlt.

Gruß, Tom

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

---

Hy

das mit den Blocknamen kenn ich auch von Brandschutz , wobei man da in der Regel nichts auswerten muß.
Aber das mit den mehreren Programmen / extend Data gab und gibt es sobald du nicht 1 Büro hast.

Elektro macht Büro A, Lüftung Büro B ab Hautverteiler im Stockwerk und EDV mit extra Stromversorgung hab ich hier bei jedem Umbau , und der Planer haut alles zusammen

Aber interessantes Thema denke Abo ist da auch das beste , weil jeden Tag braucht man es nicht in der Regel.

cu cw

------------------
Also ich finde Unities gut ... und andere sicher auch
------------------------------------------------
cadwomen™
Plant ist nur die Spitze des Berges der da treibt ?

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

---

aaa-neuerTest-Elektroymbole_ACD.dwg

Nach Blick in die Datei.

>> Mir fällt als einziger Grund dafür, die DWGs so unbrauchbar zu machen, nur der Wunsch der Programmierer ein,
>> die Elektrobetriebe, die das z.B. für Angebotserstellung auswerten müssen, zum Kauf der teuren Anwendungen zu motivieren.

>> Die Blockreferenzen der Elektrosymbole werden in diesen DWGs - vorsätzlich! - wirklich extrem unbrauchbar gemacht.

Also ich kenne zwar genau diese Fälle (Tools welche dafür geschaffen wurden), aber da geht es eher um Fertigung/Maschinenbau

In deiner DWG sehe ich das überhaupt NICHT!
Die Geomtrie ist ganz sauber, nur die Struktur/Umgang mit Blöcken und deren Referenzen nicht.

Eigentlich wäre das nun mein Text gewesen - aber weiter unten komme ich noch einmal darauf zu sprechen:
- - -
Das ist einfach ein DXF/DWG-Export aus einem nicht DXF/DWGnativen Programm
und die Erklärung für das Resultat: EINFACHE Lösung für die Umsetzung der Konvertierung,
aber nicht die "billgste", denn dann wäre es keine Blöcke/Blockreferenzen, sondern Einzelteile.

Hier geht es IMHO auch nur um ein Programm, oder Exportkern welcher in mehreren Programmen stecken könnte.

Ich hatte überhaupt nicht mit Blöcken gerechnet.

Als ACAD-User würde ich je eine Symbolkopie (zB. Steckdose230V usw. ordentlich ausrichten und dann loslegen.
Auf das Auflösen verzichtete ich jetzt, ebens auf das Ausrichten. Ergebnis anbei
(Nur eine Symbolkopie wollte er nicht und bei 2-3 Symbole mußte ich zwei Mal zuweisen)

Als BCAD-User kommen mir die Blocknamen bekannt vor, es ist genau der Namenaufbau welcher Bricscad für Blockify nutzt!
Also die Funktion welche aus einem Objekthaufen Blöcke machen kann.
Heute erstellt BCAD natürlich einen Block mit vielen Bockreferenzen, skaliert, gedreht- so wie nötig und sinnvoll.
[i][/i]

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

---

Zitat:

---

Original erstellt von cadwomen:

Aber das mit den mehreren Programmen / extend Data gab und gibt es sobald du nicht 1 Büro hast.

---

Also XDATA sind erst mal nur Daten, und die kannst Du für alles nutzen. In aller Regel werden sie von Programmen verwendet, um anwendungsspezifische Daten anzuhängen, die dann bei Bedarf ausgewertet werden können. Das könnten im Fall von Elektrosymbolen beispielsweise Hersteller, Produktbezeichnung, Artikelnummer, Strombelastbarkeit, uswusuf sein.

Und natürlich speichert jedes Programm die Daten, die es braucht, auf seine eigene Weise. Genau so wie der Programmhersteller "XYZ" die Steckdosensymbole vielleicht auf den Layer "XYZ_STECKDOSEN" legt, legt sie ein anderer auf den Layer "X#Y#-123A", und der dritte überlässt Layer und alles andere, was Anwender beeinflussen können, alleine dem Anwender, und hängt unter dem Appnamen "FIRMA-ABC" den Wert "STECKDOSENSYMBOL" als XDATA an.

Und so eine Architekturzeichnung geht dann als DWG durch viele Hände, durch viele Planungs- und Ingenieurbüros mit vielen verschiedenen Anwendungsprogrammen, und dann geht das ganze als Ausschreibung an ein Elektro-Ausführungsunternehmen, das sich dann die vielen verschiedenen Steckdosensymbole, die in verschiedenen Büros mit verschiedenen Anwendungsprogrammen eingefügt wurden, irgendwie zusammensuchen muss, um zu wissen, dass hier insgesamt 17.389 Steckdosen eingebaut werden müssen. Und dann zähle mal diese 17.389 Steckdosensymbole ...

Das wirklich Unangenehme ist, dass einige Programmhersteller ihre Daten vorsätzlich verhunzen. Ich würde als leitendes Architekturbüro darauf bestehen, dass beteiligte untergeordnete Planungsfirmen die Daten in der DWG in einer allgemein nutzbaren Form halten müssen, und würde bestimmte Kriterien dafür festlegen.

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

---

Zitat:

---

Original erstellt von cadffm:

Die Geomtrie ist ganz sauber, nur die Struktur/Umgang mit Blöcken und deren Referenzen nicht.

---

Nöö, die Geometrie ist nicht sauber, wie Du bei genauerem Hinsehen sehen kannst. Da sind die Winkel zwischen den Linien in Schaltersymbolen oft sehr gering unterschiedlich, Die Linien nicht genau gleich lang uswusf.. Damit wird erschwert, dass ein Programm auf einfache Weise die Blöcke dann doch wieder einer konkreten Symbolart zuordnen kann.

Auch bei einer Konvertierung ins DWG-Format aus einem anderen Programm heraus würde man sinnvollerweise die Blocknamen so ausgeben, dass Steckdosen als Steckdosen und Schalter als Schalter erkannt werden können. Ein Programm, das für die weitere Planung benötigte DWGs so verhunzt erzeugt, ist keinen Cent wert. Sowas würde kein Programmierer machen.

Zitat:

---

Als ACAD-User würde ich je eine Symbolkopie (zB. Steckdose230V usw. ordentlich ausrichten und dann loslegen.

---

Dann viel Spaß damit, wenn Du in einer DWG zehntausende Steckdosen hast, die Du jeweils einzeln suchen musst, um dann an die passende Position eine eigene Blockreferenz zu setzen.

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

---

>>Nöö, die Geometrie ist nicht sauber, wie Du bei genauerem Hinsehen sehen kannst.
Nun, ich habe genau hingesehen, aber natürlich nur in 3-4 Stichproben
und da AutoCAD aus der Box die Geometrie als identisch genug erachtete,
habe ich auch nicht weiter nach Problemen gesucht.

Aber du darfst gerne mal 1-2 dieser Fälle konkret zeigen (einwolken / färben, wie auch immer), dann kann man leicht über dasselbe reden.

Aber wie erwähnt, bei 2-3 Symbolen waren mal Abweichungen drin,
also habe ich dann einmal nach Vorlage1 10 Symbole gefunden und danach
noch weitere Kopien dieses Symbols gesehen (also mit Abweichungen zu Vorlage1),
so mußte ich für die Vorlage2 den Vorgang erneut durchführen und weil ich (Mensch/Auge)
erkannte das es dasgleiche Symbol sein soll, habe ich diese 15 Treffer dem neuen
Block für Vorlage1 zugeordnet.

Aber! Das das findest du in "jedem" CAD Plan, da nimmt man mal einen Schalter aus der einen Datei,
dann aus der anderen und dann sind das eben anders benannte, anders definierte, aber sie sollen
dasselbe Symbol darstellen, zB. einen Schalter.
2 fast identische Symbole, per Auge nicht zu unterscheiden und jeweils 10-15-fach verwendet,
SOWAS würde kein Programmierer machen der einem das Leben schwer machen will   ,
denn dann ist jedes Symbol leicht unterscheidlich.

>>Auch bei einer Konvertierung ins DWG-Format aus einem anderen Programm heraus würde man sinnvollerweise
Hier geht es nicht um sinnvoll, sondern dem starken Druck am Markt, DXF/DWG für den Datenaustausch bereitstellen zu können - mehr nicht, also möglichst einfach/günstig.

>>Ein Programm, das für die weitere Planung benötigte DWGs so verhunzt erzeugt, ist keinen Cent wert."
Keiner wird gezwungen diese nicht-DXF/DWG Software zu kaufen und schon gar nicht um damit DXF/DWG zu erzeugen.

>>Sowas würde kein Programmierer machen"
Da irrst du dich aber 100.00%ig
und darüber hinaus: Was interessiert HerstellerX den Rotz in einem DXF/DWG Export, der ohnehin nicht mehr in seiner Software bearbeitet wird?

<<Zitat: Als ACAD-User würde ich je eine Symbolkopie (zB. Steckdose230V usw. ordentlich ausrichten und dann loslegen.>>
>Dann viel Spaß damit, wenn Du in einer DWG zehntausende Steckdosen hast, die Du jeweils einzeln suchen musst, um dann an die passende Position eine eigene Blockreferenz zu setzen.
Verstehe ich nicht, aber vermutlich weil du es nicht verstanden hast:

Es gibt nur eine 230V Steckdose, ich würde ein ordentlich ausgerichtetes Symbol nehmen, oder eine Kopie entsprechend sauber ausrichten.
Das Programm (ACAD/BCAD oder andere) erzeugen dann einen neuen Block oder setzen einen vorhandenen für die
10.000 Steckdosen ein.
Ich muss da nichts suchen und setzen, das macht ja das Programm für mich.

 

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

---

>>Sowas würde kein Programmierer machen"
Vielleicht keine freischaffenden Künstler wie du, aber auch dafür müßte man zunächst mal die IST-Situation kennen und auch wieviel der Progger von DXF/DWG versteht (für gewöhnlich wohl nichts, wenn der in einem anderen/eigenen Format fit ist).

Ich wollte nur darauf hinweisen das die meisten Programmierer mit so einer Aufgabe
wohl Leibeigene der Auftraggeber bzw. Arbeitgeber sind.
Machen wir toll => 100.000€
Machen wir schnell => 10.000€
Was wird der Entscheidungsträger wohl befehligen, wenn es eine Leistung ist die er am liebsten überhaupt nicht machen würde?

-

Ich zeige ja nur andere denkbare Konstellationen auf, zudem sehe ich hier wirklich keine Absicht
(keine/kaum individuellen Anpassungen pro "Symbol", nur Drehungen - was normal ist. Nicht mal Skalierungen, was aber auch normal wäre.)

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

---

Zitat:

---

Original erstellt von cadffm:

Verstehe ich nicht, aber vermutlich weil du es nicht verstanden hast:

Es gibt nur eine 230V Steckdose, ich würde ein ordentlich ausgerichtetes Symbol nehmen, oder eine Kopie entsprechend sauber ausrichten.
Das Programm (ACAD/BCAD oder andere) erzeugen dann einen neuen Block oder setzen einen vorhandenen für die
10.000 Steckdosen ein.
Ich muss da nichts suchen und setzen, das macht ja das Programm für mich.

---

Ich vermute, Du verstehst da was nicht richtig. Wie willst Du denn die tausende Steckdosen-Blöcke finden, die alle unterschiedliche, nichtssagende Blocknamen haben? Und wie willst Du sie dann durch einen Block Deiner Wahl ersetzen, wenn alle Einfügepunkte 0,0,0 sind, und wenn alle Rotationen 0 sind, obwohl die Darstellungen gedreht sind? Welches Programm macht das für Dich?

Ein Programm zu schreiben, das genau das macht, war ja meine Aufgabe.

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

---

>>Ich vermute, Du verstehst da was nicht richtig.
Doch doch und dein Beispiel ist ja sogar ein leichtes Beispiel, weil es schon Blöcke sind.
So muss "ToolX" nicht noch schwerlich entscheiden welche Objekte ggf. zusammengehören - DAS ist ja viel öfters die Aufgabe!

>>Welches Programm macht das für Dich?
Alle die ich kenne, darum geht es ja!

Du hast dir offenbar mein Beispiel überhaupt nicht angesehen
und, warum auch immer, meine Aussage zu Acad und zu Bcad nicht durchgelesen.
Das ACAD-Beispiel habe ich oben angehangen.

Wie geschrieben, habe ich für den Schnellschuss nicht immer ein schön ausgerichtetes Vorgabe Symbol verwendet und ich habe die ursprünglichen Blockreferenzen auch nicht aufgelöst,
nur die Angabe eines sinnvollen Basispunktes habe ich mir nicht nehmen lassen (man hätte auch das Geometriezentrum automatisch nutzen können | | oups, beim Block "SK" hatte ich keinen ordentlichen BP angegeben).

-

Morgen schreibe ich noch etwas mehr, über Möglichkeiten, Nachteile/Wünsche.

 

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

---

Zitat:

---

Original erstellt von cadffm:
>>Ich vermute, Du verstehst da was nicht richtig.
Doch doch und dein Beispiel ist ja sogar ein leichtes Beispiel, weil es schon Blöcke sind.
So muss "ToolX" nicht noch schwerlich entscheiden welche Objekte ggf. zusammengehören - DAS ist ja viel öfters die Aufgabe!

---

Das ist hier irrelevant, denn das war hier ja NICHT die Aufgabe. Du bist auf einem völlig falschen Gleis gelandet.

Es ging nicht darum, vorhandene Zeichnungselemente wie Linien, Bögen, Kreise usw passend zueinander zu finden und aus denen Blöcke zu basteln, sondern es ging darum, unterschiedlichste Blockreferenzen als verschiedene Elektrosymbole erkennen und zählen zu können, und ihnen einen korrekten Einfügepunkt zuzuweisen (über den sie in einem Grundriss einer Wohnung oder Büroeinheit und einem Raum zugeordnet werden können).

Wie viele Wechselschalter, wie viele Antennensteckdosen usw. sind denn in der Beispiel-DWG vorhanden? Welche Programme können Dir das denn sagen? Du sagst, alle die Du kennst. Ich kenne kein einziges, und mein Auftraggeber kannte auch keine, und die anderen Programmierer, die er zuerst gefragt hat, kannten auch keine. Also bitte einfach mal Beispiele nennen.

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

---

Ich gebe mir Mühe:

>>Es ging nicht darum, vorhandene Zeichnungselemente wie Linien, Bögen, Kreise usw passend zueinander zu finden und aus denen Blöcke zu

basteln,
AUCH wenn man eigentlich keine Blöcke erstellen/ersetzen möchte, Teilaufgabe ist es gleiche "Symbole" zu erkennen (Objekthaufen oder

Blöcke/Blockreferenzen, ob das nun neue Blöcke werden oder auch nicht - wie auch immer).

>>sondern es ging darum, unterschiedlichste Blockreferenzen als verschiedene Elektrosymbole erkennen und zählen zu können,
Ja, das habe ich auch immer als eigentliches Ziel angesehen, egal wie man dahin kommt.

>>und ihnen einen korrekten Einfügepunkt zuzuweisen
Das wäre ja noch die leichteste Übung, wenn man den einfach ins Zentrum legt, allerdings mit Tool und nicht mit nativen Befehlen der

Programme.

>>Wie viele Wechselschalter, wie viele Antennensteckdosen usw. sind denn in der Beispiel-DWG vorhanden?
>>Welche Programme können Dir das denn sagen?"
Zunächst kein mir bekanntes Programm.

>>Du sagst, alle die Du kennst."
Nein, ich sagte die Programme können:
'tausende Steckdosen-Blöcke finden, die alle unterschiedliche, nichtssagende Blocknamen haben'
'sie dann durch einen Block Deiner Wahl ersetzen'
auch wenn 'alle Einfügepunkte 0,0,0'
und wenn 'alle Rotationen 0 sind'
auch wenn 'die Darstellungen gedreht sind'
Das habe ich gesagt/gemeint,
das Programm weiß aber nicht das es ein Steckdosen Block ist, das weiß nur ich (Mensch/Auge).
Acad/Bcad und andere können einfach nur "gleiche" finden und auch immer nur für ein Symbol pro Durchgang
und auch nur in einer DWG (so ist es in ACAD zumindest).

>>Ich kenne kein einziges"
Ich auch nicht, wenn es darum geht ein Symbol als Steckdose und ein anderes als Leuchtenauslass zu identifizieren.
Wenn ich deine Zeilen richtig interpretiere, dann prüfst du aber anhand der CAD-Inhalte "bekannter" Blöcke,
du würdest also einen gleich aussehenden Block, intern aber völlig anders aufgebaut, nicht erkennen. Richtig?

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

---

Zitat:

---

Original erstellt von cadffm:

Wenn ich deine Zeilen richtig interpretiere, dann prüfst du aber anhand der CAD-Inhalte "bekannter" Blöcke

---

Da interpretierst Du falsch. Nein, es gibt keine bekannten Blöcke. Du hast die DWG, die ich hier eingestellt habe, und hast sonst nur allgemeine Informationen über das Aussehen unterschiedlicher Elektrosymbole.

Beispielsweise die als Steckdosen zu interpretierenden Blöcke sind nicht völlig gleich, aer natürlich auch nicht völlig unterschiedlich. Wären sie völlig unterschiedlich, dann könnte auch der Mensch sie durch Inaugenscheinnahme nicht mehr als Steckdosen zuordnen.

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

---

Als Planer für Elektro erscheint mir dieser Fall sehr ungewöhnlich.
Wir geben nie DWGs zur Ausschreibung / Angebotserstellung, immer nur PDFs.
Bei größeren Projekten gibt es sowieso eine genaue Definition der Stückzahlen, wozu also im Plan nachzählen?
Natürlich gibt es da schelmische Firmen, die herausfinden wollen, ob eine Position gar nicht gebraucht wird, und dann einen niedrigen oder gar Nullpreis einsetzen um bei der Auswertung besser abzuschneiden. Das kann aber auch Ausschlussgrund sein, wenn es auffällt.

Ähnlich wie cadffm vermute ich, dass die "Verhunzung" der Blöcke keine Absicht ist, sondern Ergebnis der Konvertierung von Proxy-Elementen und XREF-Bindeaktionen. Eventuell wurde sogar mal eine PDF oder ein Bestandsplan eingelesen.

Ich sehe da nicht wirklich einen Markt.

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

---

Hi,

>>"Als Planer für Elektro erscheint mir dieser Fall sehr ungewöhnlich. Wir geben nie DWGs zur Ausschreibung / Angebotserstellung, immer nur PDFs."
Interessant wie man etwas als sehr ungewöhnlich darstellt und im nächsten Satz direkt eine Erklärung liefert warum das so kommen kann. 
Aus PDFs könnte man recht schnell eine CAD-Datei generieren, welche genau so wie dieses CAD-Beispiel aussieht.

>>"Bei größeren Projekten gibt es sowieso eine genaue Definition der Stückzahlen,"
Das sehe ich aus Erfahrung anders, es gibt nicht immer einfach herauszulesene Gesamtstückzahlen, ganz im Gegenteil.

Einzig in Plänen kann man sich einigermaßen an den Symbolzahlen orientieren und zudem:
>>" wozu also im Plan nachzählen?"
Weil man keinen Quatsch berechnen möchte und durch das Nachzählen die evtl. vorhandenen Stückzahlen überprüft werden können.
Da habe ich nicht selten Abweichungen von +/-100%  - Fehler sind menschlich.

>>"Natürlich gibt es da schelmische Firmen, die herausfinden wollen, ob eine Position gar nicht gebraucht wird,"
>>"und dann einen niedrigen oder gar Nullpreis einsetzen um bei der Auswertung besser abzuschneiden."
>>"Das kann aber auch Ausschlussgrund sein, wenn es auffällt."
Ausschluss weil jemand mitdenkt? Bedenklich 

>>"Ich sehe da nicht wirklich einen Markt."
Ich würde den schon sehen, aber so ein Programm kann kein Selbstläufer sein. Nötige Vorarbeit und Nacharbeit darf man nicht unterschätzen.
Random Beispiel: Unterschiedlich gefärbte Symbole mit selber Geometrie = Unterschiedliche Bedeutung
und das kann ja immer anders sein - das bekommt man nicht automatisiert in den Griff, da muss man selbst dran.

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

---

Zitat:

---

Original erstellt von cadffm:
Hi,

[i]
Aus PDFs könnte man recht schnell eine CAD-Datei generieren, welche genau so wie dieses CAD-Beispiel aussieht.

---

Nöö, wie willst Du das denn hinkriegen? Das Programm zur Konvertierung von PDF nach DWG müsste dann ja die Blöcke generieren, und das geht nur dann, wenn es Elektrosymbole von anderen graphischen Elementen unterscheiden kann. Und wenn es das schon kann - was ganz und gar nicht trivial ist - dann könnte es ja auch gleich die unterschiedlichen Arten von Elektrosymbolen erkennen.

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

---

Zitat:

---

Original erstellt von Triple-S:
Ich sehe da nicht wirklich einen Markt.

---

Vielen Dank für die klare Einschätzung. Da sich ja auch sonst keine Elektriker gemeldet haben, sehe ich das nun auch so wie Du. Ich stampfe das Programm also einfach ein.

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

---

aaa-TestV1.dwg

Eine Problematik die ich zugut kenne.... Besonders wenn im laufe des Lebenszyklus einer DWG, unterschiedliche Planer mit unterschiedlichen Werkzeugen daran rumpfuschen. Fünf verschiedene Darstellungen eines z.B. Brandmelders der das selbe tut sind nicht selten.
Das Tool klingt interessant, aber für die DWG die du da bereit gestellt hast, brauch ich ca. 15-20min zum Strukturieren mit Standard ACAD2025 Werkzeugen, je nach Menge der MurksDWG eine akzeptable Zeit. In angehängter DWG habe ich jetzt nicht sonderlich auch die BlockNamen geachtet, aber auswertbar wäre es. Trotzdem interessant, besonders bzgl. der Lernfähigkeit

------------------
Wer immer tut, was er schon kann, bleibt immer das, was er schon ist.

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

---

Zitat:

---

Original erstellt von C4DP4P57:
für die DWG die du da bereit gestellt hast, brauch ich ca. 15-20min zum Strukturieren mit Standard ACAD2025 Werkzeugen

---

Logisch, aber das ist ja nur eine Beispieldatei. Bei meinem Kunden ging es typisch um ca 10.000 Symbole je DWG, in der Spitze an die 100.000, und am Anfang belief sich der Auftrag auf die Erkennung von 26 verschiedenen Elektrosymbolarten, die auf jeweils dutzende verschiedene Arten dargestellt wurden (aber immer als Blöcke!). Die DWGs enthielten natürlich nicht nur die Elektrosymbole, sondern waren komplexe Architekturzeichnungen mit allen möglichen anderen Zeichnungselementen und auch völlig anderen Blöcken, die Elemente aus anderen Gewerken modellierten. Die Blöcke waren sehr unterschiedlich definiert, also nicht immer so wie in der Beispieldatei, wo die Blöcke eher so wie anonyme Blöcke waren, mit einer Definition und nur je einer Referenz dazu.

Die Lernfähigkeit wurde erst in einem Folgeauftrag gefordert. Da klickt der Anwender dann ein bisher unerkanntes Elektrosymbol, und gibt dem einen Namen, und das Programm erkennt dann alle gleichartigen Blöcke, auch wenn das Referenzen auf andere Blockdefinitionen sind, und es speichert die Geometrie in einer Datenbank, die zuküftig auch bei allen weiteren Auswertungen mit berücksichtigt wird. Es hat sich gezeigt, dass die Erkennung da nicht so breite Abweichungen berücksichtigen muss. Das ist dann eher so, wie cadffm das weiter oben schon mal angedacht hatte.

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

---

@Archtools

>"Da interpretierst Du falsch. Nein, es gibt keine bekannten Blöcke."
Du hast die DWG, die ich hier eingestellt habe, und hast sonst nur allgemeine Informationen über das Aussehen unterschiedlicher Elektrosymbole."

Das meine ich, "allgemeine Informationen" = du gehst davon aus das ein Leuchtenauslass aus zwei Linien besteht.
Wenn man das dann noch verfeinert, dann haben die auch ca. 90° zueinander und die Mittelpunkte liegen auf nach zusammen.
Je nachdem wie genau/aufwändig man das machen möchte/muss und an Performance ausgeben will.
Es werden die CAD-Daten geprüft und nicht eine (externe) Möglichkeit welche grafische Formen vergleicht,
also Lisp only? Cool.

>"Wären sie völlig unterschiedlich, dann könnte auch der Mensch sie durch Inaugenscheinnahme nicht mehr als Steckdosen zuordnen."
Ja doch, völlig unterschiedlich im CAD-Aufbau kann dennoch optisch gleich sein, der Mensch hat damit kein Problem
und im Gegenteil, der Mensch könnte es überhaupt nicht unterscheiden.

Wäre zB. der Leuchtenauslass = ein einfaches Kreuz:
VarianteA zwei kreuzende Polylinien
VarianteB kreuzende Polylinie und Linie
VarianteC zwei kreuzende Linie
VarianteD vier sich treffende Linien
usw.
Das wäre dann nur mit einem optischen Vergleich sinnvoll möglich.

Ich finde das spannend. "Sowas" habe ich auch schon nutzen müssen, aber immer nur "dumm" programmiert und nur für recht wenige Symbole. Als allgemeingültig funktionierendes Tool ist das aber eine andere Sache, toll.

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

---

Zitat:

---

Original erstellt von cadffm:
@Archtools

[i]>"Da interpretierst Du falsch. Nein, es gibt keine bekannten Blöcke."
Du hast die DWG, die ich hier eingestellt habe, und hast sonst nur allgemeine Informationen über das Aussehen unterschiedlicher Elektrosymbole."

Das meine ich, "allgemeine Informationen" = du gehst davon aus das ein Leuchtenauslass aus zwei Linien besteht.
Wenn man das dann noch verfeinert, dann haben die auch ca. 90° zueinander und die Mittelpunkte liegen auf nach zusammen.
Je nachdem wie genau/aufwändig man das machen möchte/muss und an Performance ausgeben will.
Es werden die CAD-Daten geprüft und nicht eine (externe) Möglichkeit welche grafische Formen vergleicht,
also Lisp only? Cool.

Wäre zB. der Leuchtenauslass = ein einfaches Kreuz:
VarianteA zwei kreuzende Polylinien
VarianteB kreuzende Polylinie und Linie
VarianteC zwei kreuzende Linie
VarianteD vier sich treffende Linien
usw.

---

Oh ja, und da gibt es viele, viele weitere Möglichkeiten. Solche Blöcke werden auch gerne mal von absoluten CAD-Laien definiert, und da gab es konkret bei diesen simplen Leuchtendarstellungen auch viele andere Varianten. Beispielsweise zerstückelte, und sich teilweise überlappende und übereinander liegende Linien, so dass also scheinbar nur zwei sich kreuzende Linien zu sehen waren, das Teil aber aus 7 Linien bestand. Und die Winkel, in denen die sich kreuzen, waren oft mal 89,9997° anstatt 90°, und die scheinbaren (wg Überlappungen aufeinander liegender Linien) Längen unterschieden sich auch gerne mal nach der 5. Nachkommastelle.

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

---

Hallo Tom,

auch wenn ich kein Elektroplaner bin und momentan keine konkrete Anwendungsmöglichkeit auf meinem Gebiet (Metallbau) sehe, klingt das Ganze durchaus interessant.

Vor allem, wenn Dein Programm tatsächlich mit einer Art lernfähiger Geometrie-Erkennung arbeitet und man die Anwendung vielleicht ein wenig über den Tellerrand Richtung BIM denkt.

Da sollte sich durchaus ein Markt finden ... preislich? ... aus dem Bauch heraus für ein Büro, das sich mit Plänen von zig Zulieferern/Gewerken auseinandersetzen muss ... da klingt so ein Jahres-Abo mit 70-100 Euro absolut interessant ... angesichts der von mir vermuteten Leistung vielleicht sogar noch zu tief angesetzt.

Grüße
Gernot

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

---

Zitat:

---

Original erstellt von ArCADe-Spieler:
ein Jahres-Abo

---

Danke für Deinen Input, aber ich war noch nie ein Freund von Software im Abo-Modell (oder auch jeder anderen Art von langer zeitlicher Bindung, egal ob Leasing-Autos oder Frauen  ). Ich habe sowas selbst immer verweigert, und will mir als Einzelunternehmer auch nicht den enormen Verwaltungsakt zumuten, um die Abos dann zu verwalten. Ich bin ja nun seit 2 Jahren im Ruhestand, und die Aufräumarbeiten fanden genau deshalb statt, um zu sehen, was sich von meinen vielen Programmierarbeiten noch wirtschaftlich verwerten lässt, ohne dass das für mich großen Aufwand mit sich bringt.

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

---

Wechsel-Serie-Block.JPG

@Archtools
>"Da sich ja auch sonst keine Elektriker gemeldet haben"
Das Tool ist doch viel allgemeinerer Natur und hat im Grunde nichts mit speziell Elektro zutun,
auch wenn es aktuell darauf vorbereitet ist.

>"Ich stampfe das Programm also einfach ein"
Ich kann es verstehen.
Aber dann können wir ja ein wenig über die Umsetzung sprechen, also anhand eines Beispiels
damit man es versteht und von deiner Erfahrung lernt.
Mich zumindest würde es sehr interessieren, da ich bisher so allgemein noch keine Ermittlung versucht habe, zumindest nicht erfolgreich.

Welche Informationen hast du zB. für einen einfachen Wechselschalter "hinterlegt"?
  /\
  O
\/

Welche Informationen werden gespeichert / was verglichen, um dann automatisch einen Schalter zu identifizieren?

und dann noch von einem Serienschalter unterscheidet
/\ /\
  O

Vermutlich muss man das ja Aufteilen, denn händisch/hardcodiert kann man ja viele "Vorgaben" festhalten bis es passt,
aber du hast auch vom "anlernen" gesprochen, also einer Automatisierung.

Automatisch ohne Vorlage = Deine hardcodierten informationen wie ein zB. Wechselschalter erkannt wird, recht einfach.
Aber was ist wenn die beiden Symbole noch nicht bekannt wären und man diese nun "anlernt", was wird dann hinterlegt?

Objekttyp+Anzahlen ist zuwenig zum eindeutigen identifizieren
Objekttyp+Reihenfolge bringt schon 95% Trefferquote (Bei Texten merkt man sich noch den Textwert).
Händisch (beim coden) kann man individuell reagieren, aber bei automatischer Ergänzung - was machst du in diesem Fall?

Blöd, eindeutig ein Thema was sich viel besser bequatschen lässt, als es schriftlich zu versuchen 
Würde mich auf jeden Fall freuen aus dem Thread ein paar Anregunden mitzunehmen.

Mir reichte bisher immer "alle gleichen finden", mit einer 95% Trefferquote.
Sowas kann man nicht verkaufen, aber sehr gut selbst nutzen.
Wenn jetzt noch eine automatische "was bist du eigentlich?" Erkennung dazu kommen würde = Luxus.

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

---

Zitat:

---

Original erstellt von cadffm:

Objekttyp+Anzahlen ist zuwenig zum eindeutigen identifizieren
Objekttyp+Reihenfolge bringt schon 95% Trefferquote

---

Wie die Reihenfolge die Erkennung verbessern kann, erschließt sich mir beim besten Willen nicht.

Das Ganze ist nicht als KI programmiert wie ein anderes, von mir inzwischen längst eingestampftes Programm namens objectiveCAD. Da geht es ganz simpel um Fallunterscheidungen und etwas Logik. Einen Schalter allgemein zu beschreiben, würde hier schon zu weit führen. Bleiben wir bei der Lampe. Deren Symbol sieht aus wie zwei sich in den Mittelpunkten annähernd senkrecht kreuzende, annähernd gleich lange Linien, eventuell auch noch mit einem Kreis drum herum, dessen Mittelpunkt annähernd im Schnittpunkt der Linien liegt, und der Radius annähernd die halbe Länge einer Linie ist.

Nun prüft mein Programm nicht auf zwei Linien-Entities mit einem eventuellen Kreis-Entity drum herum, sondern sucht sich erst mal alle Linien- und Polylinienstückchen zusammen, die auf einer Linie liegen. Ob eine der sich kreuzenden Linien aus sich überlappenden, annähernd auf einer Geraden liegenden einzelnen Stückchen besteht, ist irrelevant. Somit findet das Programm schon mal alles, was so aussieht wie eine einzelne Linie, egal aus wie vielen Stücken welchen Enititytyps und mit welchen Überlappungen und winzigen Lücken dazwischen das auch tatsächlich erzeugt worden ist.

Auch Kreise sind häufig nicht als ein Kreis-Entity dargestellt. Es wird auch da aus den Entities ein virtueller Kreis abgeleitet, der z.B. aus einer Polylinie mit zwei Halbkreisen bestehen kann, oder aus beliebig vielen Kreisbögen mit gleichem Zentrum und gleichem Radius, die sich irgendwie zu einem Vollkreis zusammen setzen.

In einem ersten Durchgang werden aus allen referenzierten Blockdefinitionen solche virtuelle Geometrien ermittelt, und dann wird jede einzelne geprüft, welcher Geometrie sie entspricht.

Diese Prüfung erfolgt dann also nicht mit der Anzahl der Enitities, sondern mit der Anzahl dieser virtuellen Linien, Kreise und Bögen. Und dann hat eine Lampe je nach Darstellung 0 oder 1 Kreis, und 2 Linien. Dann noch die Prüfung, ob die 2 virtuellen Linien sich annähernd in den Mittelpunkten schneiden, und ob der Winkel zwischen ihnen ungefähr 90° ist, und ob die freien Endpunkte der virtuellen Linien annähernd auf dem Kreis liegen. Das läuft dann einfach durch ein umfangreiches COND. Jede Blockdefinition wird damit entweder als Elektrosymbol erkannt, oder eben nicht.

[Diese Nachricht wurde von archtools am 08. Mai. 2025 editiert.]

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

---

>>"Wie die Reihenfolge die Erkennung verbessern kann, erschließt sich mir beim besten Willen nicht."
Da sprech ich von (einfachen) Wegen um "alle gleichen" Blöcke zu finden, ganz low level
und auch nur für so schöne Laborbedingungen wie hier im Beispiel.

Je Block sind Objekttyp+Anzahlen zuwenig zum eindeutigen identifizieren,
Objekttyp(oder bei Texten, der Textwert)+Reihenfolge bringt schon gut 95% Trefferquote.
Warum nicht 100%, weil zum Beispiel Serien- und Wechselschalter beide denselben Aufbau haben - was Objekttypen/Anzahl/Reihenfolge angeht.
ARC LINE LINE LINE LINE

Die Gesamtliste
(((ARC LINE LINE LINE LINE) Textblock1)((ARC LINE LINE LINE LINE) Textblock2)((ARC KLINGEL CIRCLE LINE) Textblock3)..)
und dann einfach vergleichen welche Blöcke denselben Aufbau haben.

Irgendwann einmal eine Stunde für Code investiert und damit dann das "suche alle Gleichen" Problem fast komplett gelöst zu bekommen.
Natürlich kommt das stark auf die Daten an, aber im DWG-Beispiel hier, sind es nur Serien- und Wechselschalter welche man damit "fälschlich"
als "gleich" ermittelt.
Leider weiß weder ACAD noch das Tool um was es sich handelt, daher kann auch die Benennung der Treffer nicht vollautomatisch erfolgen.
Die billige Methode ist dann: Einen Symbolnamen händisch eintippen, oder aus einer vordefinierten Liste auswählen.

Damit es dann in anderen Dateien aus derselben Quelle weitergenutzt werden kann - Liste exportieren / Liste importieren - dieses Mal mit dem Wunschnamen verknüpft.
(((LINE LINE) LEUCHTENAUSLASS)((ARC LINE LINE LINE LINE LINE LINE LINE LINE) KREUZSCHALTER)..)

Alles was darüber hinausgehen würde, ist für mich in keinem vertretbaren Verhältnis zwischen Aufwand und Nutzen gewesen.
Vielleicht ändert sich das ja ab heute und diesem Thread.

_ _ _

>>"Einen Schalter allgemein zu beschreiben, würde hier schon zu weit führen."
Schade

>>"Bleiben wir bei der Lampe." (Lampenauslass)
>>"Deren Symbol sieht aus wie zwei sich in den Mittelpunkten kreuzende, annähernd gleich lange Linien, eventuell auch noch mit einem Kreis drum herum,
>>"dessen Mittelpunkt annähernd im Schnittpunkt der Linien liegt, und der Radius annähernd die halbe Länge einer Linie ist."

>>"Nun prüft mein Programm nicht auf zwei Linien-Entities mit einem eventuellen Kreis-Entity drum herum, sondern sucht sich erst mal alle Linien- und Polylinienstückchen zusammen,"
Soweit, so gut, so klar

>>"die auf einer Linie liegen."
Puh, das sind/können dann ja auch mehrere verschiedene "auf einer Linie" sein, oder halt keine "mehrere" auf einer Linie.
Hier wäre ich schon ausgestiegen   

>>"Ob eine der sich kreuzenden Linien aus sich überlappenden, annähernd auf einer Geraden liegenden einzelnen Stückchen besteht, ist irrelevant."
>>"Somit findet das Programm schon mal alles, was so aussieht wie eine einzelne Linie, egal aus wie vielen Stücken welchen Enititytyps"
>>"und mit welchen Überlappungen und winzigen Lücken dazwischen das auch tatsächlich erzeugt worden ist."

Mal überlegen wo wir jetzt sind, die sublisten enthalten alle "in fast einer Linie" Objekte, also je sublist = 1x "in einer Linie":

Variante a (Symbol aus zwei Linien oder Polylinien)
Programm ermittelt ((Linie1)(Linie1))
Variante b1 (Symbol aus vier Linien)
Programm ermittelt ((Linie1 Linie3)(Linie2 Linie4))
Variante b2 (wie b1, aber zum Teil gibt es doppelte Objekte)
Programm ermittelt ((Linie1 Linie3 Linie4 Linie5)(Linie2))
In allen Fällen sehe ich also als Ergebnis ZWEI "linien", ob mit oder ohne Lücken ist mir mal egal an dieser Stelle.

>>"Auch Kreise sind häufig nicht als ein Kreis-Entity dargestellt. Es wird auch da aus den Entities ein virtueller Kreis abgeleitet, der z.B. aus einer Polylinie mit zwei Halbkreisen bestehen kann,"
>>"oder aus beliebig vielen Kreisbögen mit gleichem Zentrum und gleichem Radius, die sich irgendwie zu einem Vollkreis zusammen setzen."
Ja, immer wieder interessant. Hier sind es im Thread nahezu geschlossene Bögen.

>>"In einem ersten Durchgang werden aus allen referenzierten Blockdefinitionen solche virtuelle Geometrien ermittelt, und dann wird jede einzelne geprüft, welcher Geometrie sie entspricht."

>>"Diese Prüfung erfolgt dann also nicht mit der Anzahl der Enitities, sondern mit der Anzahl dieser virtuellen Linien,"
Bis hierhin würde ich dann für mich sagen: Okay
Allerdings ist die Anzahl der Objekttypen, ob real oder virtuell, nicht eindeutig genug, da fehlt noch irgendein Kleeblatt im Zaubertrank.
?

>>" Kreise und Bögen."
>>"Und dann hat eine Lampe je nach Darstellung 0 oder 1 Kreis, und 2 Linien."
Das klingt hingegen weniger lustig, das ist wohl nichts für mich.
Okay, Bögen und Polylinien, auch noch zerlegte Polygone/Liniensegmente - mach ich noch mit,
aber wenn das aus 100 Fliegenschiss zusammengebastelt ist, es gibt ja unendliche Variationen, darauf hätte ich wohl keine Lust - zumindest  nicht wenn man bei 0 anfängt.

>>"Dann noch die Prüfung, ob die 2 virtuellen Linien sich annähernd in den Mittelpunkten schneiden,"
>>" und ob der Winkel zwischen ihnen ungefähr 90° ist,"
Ja genau so wie ich das auch angefangen hatte (mit "echten" Enities), perfekt.

>>" und ob die freien Endpunkte der virtuellen Linien annähernd auf dem Kreis liegen."
Kreuz = Lampenauslass, Kreis außenherum = Lampe, ein weiterer Kreis außenherum, außerhalb der Linienenden = beleuchteter Taster
Genau so.

>>"Das läuft dann einfach durch ein umfangreiches COND. Jede Blockdefinition wird damit entweder als Elektrosymbol erkannt, oder eben nicht."

Danke für den Einblick   

Dann habe/hätte ich es also schon richtig angefangen, aber der Aufwand war und ist mir viiiel zu hoch dafür. Bin halt weder gut noch geübt.
Und da rede ich auch nur von richtigen Objekten, was natürlich ein Grund für die Eingeschränktheit ist, bei so einem BTN Helferlein.

Mit "virtuellen" Linien und Kreisen + Bögen hast du diese Hürde anscheinend sauber umschifft, KLASSE!
Eindeutig mehr wie 60min investiert, aber immerhin auch bezahlt bekommen

Das lasse ich jetzt erst einmal sacken.   

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

---

Zitat:

---

Original erstellt von cadffm:

Puh, das sind/können dann ja auch mehrere verschiedene "auf einer Linie" sein, oder halt keine "mehrere" auf einer Linie.
Hier wäre ich schon ausgestiegen

---

Warum das denn? Das ist doch insgesamt eine äußerst triviale Prüfung. Die geht einfach nacheinander die immer ziemlich überschaubare Zahl von Entities in einer Blockdefinition durch, und guckt, ob irgend ein anderes Entity aus dieser Liste, das wie eine Linie aussehen könnte, irgendwie dran oder drauf passt und die gleiche Richtung hat. Und dann nimmst Du einfach die beiden am weitesten voneinander entfernten Endpunkte dieser Linienstückchen und gibst als virtuelle Linie '(LINE <APKT> <EPKT>) zurück.

Zitat:

---

Allerdings ist die Anzahl der Objekttypen, ob real oder virtuell, nicht eindeutig genug, da fehlt noch irgendein Kleeblatt im Zaubertrank.

---

Ich sehe keinen Bedarf für irgendwelche Magie. Und gearbeitet wird trivialerweise immer nur mit virtuellen Entities, die aus völlig verschiedenen, beliebig vielen anderen realen Entities zusammengesetzt sind. Damit machst Du Dein Programm viel einfacher erweiter- und reparierbar.

Was allerdings schwer wäre, aber bei meinem Kunden nie vorkam und deshalb keiner Lösung bedurfte, waren komplexe Entities wie Splines. Bei Elektrosymbolen kommen schon mal Wellen in Form einer Tilde vor, und die könnte man anstatt aus zwei Bogenteilen auch mit einer Spline darstellen. Die Mühe hab' ich mir nicht machen müssen.

Zitat:

---

>>" Kreise und Bögen."
>>"Und dann hat eine Lampe je nach Darstellung 0 oder 1 Kreis, und 2 Linien."
Das klingt hingegen weniger lustig, das ist wohl nichts für mich.
Okay, Bögen und Polylinien, auch noch zerlegte Polygone/Liniensegmente - mach ich noch mit,
aber wenn das aus 100 Fliegenschiss zusammengebastelt ist, es gibt ja unendliche Variationen, darauf hätte ich wohl keine Lust - zumindest  nicht wenn man bei 0 anfängt.

---

Das geht völlig trivial in einer einzigen überschaubaren Funktion. Ob es dann bloß 1 reales Linienentity ist, oder ob es 100 sind, die zusammen genommen aussehen wie eine Linie, ist dann völlig egal und braucht keiner weiteren Programmierung, wenn man es von Anfang an richtig angeht.

Zitat:

---

Mit "virtuellen" Linien und Kreisen + Bögen hast du diese Hürde anscheinend sauber umschifft, KLASSE!

---

Du musst ja immer auch bedenken, dass Du niemals so verquer denken kannst, wie ein CAD-Neuling das tut. Ich hab' schon "Linien" gesehen, die aus einem Polylinien-Rechteck mit 0 Breite bestanden, wo also Anfangs- und Endpunkt tatsächlich jeweils zwei übereinander liegende Vertices der Polylinie waren. Und einer hat sowas dann sogar noch in einen Block gepackt, und den für verschiedene Längen und Winkel skaliert und gedreht ...

Wenn Du's so angehst wie ich, dann brauchst Du auch in solchen abartigsten Fällen, an die Du bei der Programmierung nie gedacht hättest, das Programm nur an einer einzigen Stelle zu ergänzen, nämlich bei der Funktion "Finde-virtuelle-Linien". Da kommt einfach noch ein weiterer Absatz in das COND oder OR Konstrukt

Und solche Funktionen zum Zusammenstückeln von einzelnen Linien- und Polylinienteilchen hat doch jeder Programmierer nach einigen Jahren in seiner Toolbox, und muss sich deshalb keine Gedanken mehr darüber machen. Einfach Copy&Paste, und schon ist diese Funktion drin. Ich brauchte sowas ganz konkret schon vor etlchen Jahrzehnten, um Raumpolygone zu glätten. Selbst AutoCAD/BricsCAD fügt beim Erzeugen einer Umgrenzung nämlich Knotenpunkte ein, die, weil sie zusammen mit dem vorherigen und dem nachfolgenden Vertex auf einer Geraden liegen, in manchen Anwendungen sehr stören. Und manchmal sind die Wandenden auch noch im Fuzzy-Bereich so verknotelt, dass dann gleich drei oder mehr Punkte fast direkt übereinander liegen, obwohl keiner von denen da rein gehört.

[Diese Nachricht wurde von archtools am 08. Mai. 2025 editiert.]

[Diese Nachricht wurde von archtools am 08. Mai. 2025 editiert.]

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

---

Moin zusammen,
ich habe auch eine Funktion zum Vergleichen von Objektdaten. Zwar für einen anderen Zweck aber vergleichen und dann was machen ist ja erst mal das Selbe.

Ich nehme die Daten von entget und schmeiße alles raus was nicht zum Vergleichen taugt wie Objektreferenz, Objektname usw. damit nur die Geometriedaten übrig bleiben.
Dann nehme ich alle Koordinaten oder Abstände und runde diese mit dem Wert der Toleranz.
Die fertige Liste sortiere ich alphabetisch und packe das Ergebnis in einen String.
Ach ja ... ALLE Koordinaten versehe ich mit dem Gruppencode 10
Da jetzt ja alle Koordinaten den selben Gruppencode haben und sortiert werden ist es egal ob Anfangs- und Endpunkt vorher vertauscht waren.

Jetzt muss ich einfach nur diese Strings vergleichen.
Funktioniert seit Jahren einwandfrei.

------------------
Geht nicht, gibts nicht

Gruß
Andreas

http://kraus-cad.de

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

---

Hallo Tom,

Zitat:

---

Original erstellt von archtools:
noch nie ein Freund von Software im Abo-Modell

---

Aus meiner Sicht als Anwender verbindet sich mit dem Abo-Modell zum Einen der geringere Häppchen-Preis und zum Anderen die Hoffnung auf fortlaufende Unterstützung und eventuelle Patches/Updates.

Ein Preis für ein solches Komplettprogramm ist tatsächlich schwierig, weil Du ja Deinen (bereits erledigten ... und bezahlten?!) Progammieraufwand honoriert haben möchtest, insbesondere kleine Büros, die solch ein Programm durchaus brauchen könnten, jedoch vor großen Ausgaben in Software mit ungewissem Support eher zurückschrecken dürften.

Zumal Dein Programm - soweit ich es verstanden habe - ja "nur" aus einem gemischten Feld gleiche Dinge zusammenzählt und die Art dieser Dinge (Abbildungen) und die jeweils zugehörige Anzahl tabellarisch sortiert ausgibt?!

Aber falls(!) Dein Programm die von mir vermutete Funktionalität "lernfähige Geometrie-Erkennung" tatsächlich beinhalten sollte, wäre ich im Bedarfsfall (der aktuell nicht vorliegt) für ein gut funktionierendes Programm ohne Support bereit, als Einmalzahlung bis zu einem hohen dreistelligen Betrag zu zahlen ... €750,-.

Bei langfristigem, zuverlässigen und wirklich hilfreichem Support einen niedrigen vierstelligen ... sagen wir, bis zu €1500,-.

Grüße
Gernot

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

---

Zitat:

---

Original erstellt von ArCADe-Spieler:
weil Du ja Deinen (bereits erledigten ... und bezahlten?!) Progammieraufwand

---

Ich vermute, Du hast grob falsche Vorstellungen davon, wie sich der Preis eines "von der Stange" gekauften Programms zusammen setzt. Da ist in einem kleinen Markt mit relativ wenig verkauften Lizenzen der Anteil für die Programmierung mit 30% vom Endverkaufspreis schon sehr hoch angesetzt. Die restlichen 70% (in größeren Märkten mit mehr verkauften Lizenzen noch deutlich mehr) werden für den Aufwand des Verkaufs gebraucht. Als Beispiel aus einer anderen Branche: Der Autor eines Buchs erhält bestenfalls um die 10% vom Buchhandelspreis, in der Regel aber eher noch weniger.

Ja, mein Kunde hat mich damals natürlich gut bezahlt, aber das Programm ist so, wie es ist, ja nicht an die Allgemeinheit verkaufbar. Da müssten noch erhebliche weitere Arbeiten investiert werden, die dann zusammen mit dem bisherigen Aufwand 30% vom Endpreis ausmachen dürfen.

Ich glaube, der potentielle Markt dafür ist doch zu klein, und ich würde den noch zu leistenden Aufwand nicht wieder herein bekommen können.

Die Lernfähigkeit des Pogramms hinsichtlich neuer, bisher unerkennbarer Symbole ist aber eine relativ simple Angelegenheit. Wie ich ja schon schrieb, wird nicht bzgl der in der Blockdefinition enthaltenen Entities verglichen, sondern bzgl "virtueller" Entities. Mir fällt dafür kein besserer Name ein, aber es sind dann die scheinbaren Elemente, die das Aussehen des Blocks definieren.

Der Anwender klickt dafür eine bisher nicht erkannte Blockreferenz an, und gibt ihr einen Symbolnamen. Das Programm ermittelt dann das Aussehen der Geometrie aus den "virtuellen" Entities, und speichert diese in einer Datenbank. Und damit können dann zukünftig alle Blockreferenzen beliebiger Blockdefinitionen auch in anderen DWGs, die genau so ausehen (selbst wenn sie aus ganz andere Entities bestehen), als Symbol mit dem definierten Namen erkannt werden.

Bei diesen nachträglich "gelernten" Symbolen ist die Erkennungsqualität aber deutlich geringer, weil ich weitaus weniger Kriterien zum Vergleich ansetzen kann als bei den bekannten, fest im Programm implementierten Symbolen. Da geht es dann nur um Längen, Radien und Winkeln der virtuellen Linien und Bögen. Für die Elektrosymbole reichte diese Erkennungsqualität aber vollständig aus, die Erkennung war immer 100%. Aber ich könnte, weil ich die Schwächen kenne, leicht zwei verschieden aussehende Blöcke erzeugen, die vom Programm dann dem gleichen Symbol zugeordnet würden.

Man könnte aber diese Erkennungsqualität der nachträglich gelernten Symbole noch weiter verbessern, indem weitere allgemeine Kriterien genutzt werden. Beispielsweise könnte man - was bisher noch nicht geschieht - in die Datenbank auch mit abspeichern, dass sich z.B. zwei virtuelle Linien schneiden, dass der Schnittpunkt eine Linie in einem bestimmten Verhältnis teilt, uswusf..

[Diese Nachricht wurde von archtools am 09. Mai. 2025 editiert.]

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

---

Sorry, doppelt

[Diese Nachricht wurde von archtools am 09. Mai. 2025 editiert.]

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

---

@archtools
Mit deiner kurzen Beschreibung deiner Vorgehensweise für die Erkennung hast du bei mir was für mein Tool angestoßen 

Kurze Beschreibung meiner Idee:
Es gibt Geometrie A (alt) und Geometrie B (neu)
Wenn man von beiden alle Objekte "abtastet", vielleicht mit VLAX-CURVE-GETPOINTATPARAM (natürlich nicht nur mit ganzzahligen Parametern), und die entstandenen Koordinatenlisten vergleicht, natürlich mit Toleranz, muss doch Geometrie A gleich Geometrie B sein wenn alle Koordinaten passen. Dabei ist es auch egal ob die Koordinaten von Linien/Polylinien oder Kreis/zwei Bögen oder sonstwo herkommen. Die Koordinatenlisten brauchen "nur noch" einen klar definierbaren Nullpunkt und eine klar definierbare Richtung/Drehung. Eine Skalierung könnte vielleicht über eine Bounding-Box funktionieren.

Es entstehen quasi zwei "Pixelmuster" die übereinandergelegt passen müssen.
Ha, es ist sogar egal ob ein Objekt geteilt ist. Es können sich zwei Linien kreuzen oder auch vier Linien mit ihren Endpunkten treffen, das ist wurscht.

Ich muss das bei Gelegenheit mal ausprobieren. Im Moment vergleiche ich gleiche Objekttypen aber wenn der Objekttyp egal ist, kommt das sicher gut.

------------------
Geht nicht, gibts nicht

Gruß
Andreas

http://kraus-cad.de

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

---

Zitat:

---

Original erstellt von Andreas Kraus:
@archtools
Es gibt Geometrie A (alt) und Geometrie B (neu)
Wenn man von beiden alle Objekte "abtastet", vielleicht mit VLAX-CURVE-GETPOINTATPARAM (natürlich nicht nur mit ganzzahligen Parametern), und die entstandenen Koordinatenlisten vergleicht, natürlich mit Toleranz, muss doch Geometrie A gleich Geometrie B sein wenn alle Koordinaten passen.

---

Warum nicht einfach die Geometrie in Koordinatenpunkte auflösen, die nacheinander mit einer PLINE verbunden die ursprüngliche Geometrie beliebig genau annähern? Das sollte auch ausreichen, um Ähnlichkeit erkennen zu können. Eine Funktion, die für alle relevanten Entities so eine Punktliste generiert, hab ich hier:

Code:

---

;; den auskommentierten Funktionsaufruf (at-deactivate-osmode) kannst
;; Du leicht durch (setvar "osmode" 0) ersetzen
;; Wenn Du nur die Punktliste haben willst, dann lösche den
;; (command "._pline ...) und sammle die Punkte in einer Liste
;;
(defun at-curve->poly (en / ACCURACY el closedflag lastent len vertexnumber stparam endparam
                          diffparam startpt endpt
                      )
  (if (not AT:CURVE->POLY-ACCURACY)
    (setq AT:CURVE->POLY-ACCURACY 0.01)
  )
  (setq ACCURACY AT:CURVE->POLY-ACCURACY)
  (if (= 'ENAME (type en))
    (progn
      (setq el (entget en)
            en (vlax-ename->vla-object en)
      )
    )
    (progn
      (setq el (entget (vlax-vla-object->ename en)))
    )
  )
  (if (and (assoc 70 el) (= 1 (logand 1 (cdr (assoc 70 el)))))
    (setq closedflag T)
  )
  (setq lastent (entlast))
  (if (vlax-property-available-p en 'Length)
    (setq len (vlax-get-property en 'Length))
    (progn
      (setq len (vlax-curve-getDistAtPoint en (vlax-curve-getEndPoint en)))
      ;; Ellipsenbögen liefern vlax-curve-getDistAtParam = 0 aus:
      (if (= 0.0 len)
        (setq len (vlax-curve-getDistAtParam en 1.0))
      )
    )
  )
  (setq vertexnumber (fix (/ len ACCURACY)))
  (if (= 0 vertexnumber)
    (setq vertexnumber 1)
  )
  (setq stparam (vlax-curve-getstartparam en)
        endparam (vlax-curve-getendparam en)
        diffparam (/ (- endparam stparam) (float vertexnumber))
        startpt (trans (vlax-curve-getStartPoint en) 0 1)
        endpt (trans (vlax-curve-getEndPoint en) 0 1)
  )
  ;; (at-deactivate-osmode)
  (command "._pline" startpt)
  (while (< (+ stparam diffparam) endparam)
    (setq stparam (+ stparam diffparam))
    (setq startpt (vlax-curve-getPointAtParam en stparam))
    (command (trans startpt 0 1))
  )
  (if (= 1 closedflag)
    (command "_cl")
    (command endpt "")
  )
  ;; (at-restore-osmode)
  (if (not (eq (entlast) lastent))
    (entlast)
  )
)

---

[Diese Nachricht wurde von archtools am 14. Mai. 2025 editiert.]

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

---

Kurz getestet.
Ja, genau. Koordinatenliste zum Vergleichen.
Kriterien für Verschiebung und Drehung festlegen und Koordinaten runden um die Toleranz abzuhaken.
Sollte doch funktionieren.
Ich melde mich wenn ichs hab, kann aber etwas dauern ich hab grade einige Baustellentermine und sitze nicht so oft am Rechner.

------------------
Geht nicht, gibts nicht

Gruß
Andreas

http://kraus-cad.de

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

---

Zitat:

---

Original erstellt von Andreas Kraus:
Kurz getestet.
Ja, genau. Koordinatenliste zum Vergleichen.
Kriterien für Verschiebung und Drehung festlegen und Koordinaten runden um die Toleranz abzuhaken.
Sollte doch funktionieren.

---

Es funktioniert aber nur, wenn die zu vergleichenden Blöcke aus gleichen Entities bestehen. Wenn sie nur gleich aussehen, aber ganz verschieden erzeugt wurden, hilft Dir das nix mehr. Und wenn sie schon aus gleichen Enitities bestehen, dann kannst Du die ja gleich direkt vergleichen.

Beispiel der Kreis um ein Schalter-Symbol. So ein Kreis kann aus einem CIRCLE, zig ARCs, einer oder beliebig vielen Polylinien mit passenden Bulgen usw bestehen. Und alle sehen gleich aus und müssen, zusammen mit ein paar Teilen, die wie Liien aussehen, als Schalter erkannt werden.

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

---

Und genau das möchte ich versuchen zu umgehen.
Wenn ich z.B. eine Pixelgrafik habe ist ja auch egal ob ich eine Linie auf einmal zeichne oder mehrmals ansetze.
Im Prinzip möchte ich da hin.
Aber erst Mitte/Ende nächste Woche.

------------------
Geht nicht, gibts nicht

Gruß
Andreas

http://kraus-cad.de

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

---

BKONVERT-aaa-neuerTest.dwg

Morgen zusammen

hab mir mal die Datei geschnappt und BKONVERT in 2025 damit probiert....
klappt erstaunlich gut.

Natürlich nicht das verfolgte Ziel aber um das zu zeigen.

cu cw

------------------
Also ich finde Unities gut ... und andere sicher auch
------------------------------------------------
cadwomen™
Plant ist nur die Spitze des Berges der da treibt ?

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

---

Zitat:

---

Original erstellt von cadwomen:
Morgen zusammen

hab mir mal die Datei geschnappt und BKONVERT in 2025 damit probiert....
klappt erstaunlich gut.

---

Hallo,

BKONVERT ist wohl ein in AutoCAD enthaltener Befehl, den es in BricsCAD nicht gibt.

Ich vermute, dass der Anwender dazu eine Blockreferenz zeigen muss, und dieser den korrekten Namen (hier "Schalter") und Layer zuweisen muss. Dann erkennt das Programm alle gleichartigen Blockreferenzen und auch die Geometrien in anderen Blockdefinitionen, die genau so aussehen. Dazu löst das Programm leider die Referenzen auf, anstatt nur in deren Blockdefinitionen zu suchen. Das hinterlässt die DWG dann leider trotz des einen erkannten Symbols in einem unerwünschten Zustand. Kann man durch Setzen von Einstellungen im Befehl BKONVERT denn verhindern, dass die anderen Blockreferenzen aufgelöst werden, und dass ähnliche Geometrien innerhalb anderer Blockreferenzen nicht verändert werden sollen? Dann wäre das Programm wirklich gut brauchbar.

Aber der Schalter wurde korrekt erkannt, und auch seine Blockdefinition wurde bzgl des Ursprungs geändert, und die Referenzen bekamen den korrekten Einfügepunkt.

Würde das mit BKONVERT dann in derselben DWG trotz der aufgelösten anderen Blockreferenzen dann weiter funktionieren, um auch andere Symbole erkennen zu können?

Ergänzung: hier gefunden: https://help.autodesk.com/view/ACD/2025/DEU/?guid=GUID-FEAF709E-5664-4C67-BB6A-D23E610E16F9

[Diese Nachricht wurde von archtools am 16. Mai. 2025 editiert.]

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

---

@cadwomen
Jetzt warten wir auf denjenigen der das Beispiel zum vierten Mal macht

@Archtools
>"BKONVERT ist wohl ein in AutoCAD enthaltener Befehl, den es in BricsCAD nicht gibt."
Das war ja auch mein Beispiel oben.
BCONVERT in ACAD2025
BSEARCH in ACAD2026

In BricsCAD hast du, anders und schon deutlich länger enthalten, BLOCKIFY

>"Ich vermute, dass der Anwender dazu eine Blockreferenz zeigen muss"
Acad macht da keinen Unterschied zwischen Objekthaufen oder Block(referenz), was die "Quelle" angeht.

>", und dieser den korrekten Namen (hier "Schalter") und Layer zuweisen muss."
Acad kann einen neuen Block kreieren (Blockname vom User zu wählen),
Blockbasispunkt vom User zu wählen, oder Zentrum.
Anm: Man kann auch bestehende Blöcke als "Ziel" angeben, aber Acad ermittelt nicht selbst die "passende" Drehung.

>"Dann erkennt das Programm alle gleichartigen Blockreferenzen und auch die Geometrien in anderen Blockdefinitionen, die genau so aussehen."
oder auch nicht in-Blöcken / lose Objekthaufen.

>"Dazu löst das Programm leider die Referenzen auf, anstatt nur in deren Blockdefinitionen zu suchen."
>"Das hinterlässt die DWG dann leider trotz des einen erkannten Symbols in einem unerwünschten Zustand."
Bei dem Geometrievergleich wird alles verglichen, analysiert die Objekte also als wenn sie wirklich an der Stelle der Blockreferenz im Modell vorliegen würden.
Wirklich aufgelöst werden Blockreferenzen, sofern es denn eine betrifft, nicht, aber ausgetauscht.

>"Kann man durch Setzen von Einstellungen im Befehl BKONVERT denn verhindern, dass die anderen Blockreferenzen aufgelöst werden,"
Es werden keine Blockreferenzen aufgelöst.

>"und dass ähnliche Geometrien innerhalb anderer Blockreferenzen nicht verändert werden sollen?"
Identische Geometrie in Blöcken werden ignoriert, wenn es noch weitere Geometrie in dem Block gibt.
Quelle/Suche nach einem Kreis ermittelt alle entsprechenden Kreise und je nach Einstellung, auch entsprechende Kreis, welche sich in Blöcken befinden - welche nur aus diesem Kreis bestehen.

>"Dann wäre das Programm wirklich gut brauchbar"
Brauchbar in jedem Fall, was hier aber fehlt und ich unbedingt erwarte (und ich schon von anderer Software vor 20 Jahren bekommen hatte: In ElcoCAD),
die Arbeit des Users kann nicht auf andere Dateien angewendet werden - DAS IST MIST - müßte man also alles immer wieder für jede Datei machen.

Man kann die Suche "in Blockreferenzen" ausschließen:
Schließe alle Blöcke aus / schließe Teilblöcke aus / schließe ganze Blöcke aus / schließe alle vorhandenen Blöcke ein, ob ganze Blöcke oder Teilblöcke

>"Aber der Schalter wurde korrekt erkannt, und auch seine Blockdefinition wurde bzgl des Ursprungs geändert, und die Referenzen bekamen den korrekten Einfügepunkt.
Blöcke werden nicht geändert, sofern es Blockreferenzen betrifft, werden diese ausgetauscht.

>"Würde das mit BKONVERT dann in derselben DWG trotz der aufgelösten anderen Blockreferenzen dann weiter funktionieren, um auch andere Symbole erkennen zu können?"
Das habe ich leider nicht verstanden, aber wie zuvor gesagt: Ob Blockreferenzen oder nicht, ist zunächst vollkommen egal.

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

---

Zitat:

---

Original erstellt von cadffm:
@Archtools
>"Kann man durch Setzen von Einstellungen im Befehl BKONVERT denn verhindern, dass die anderen Blockreferenzen aufgelöst werden,"
Es werden keine Blockreferenzen aufgelöst.

---

In der Beispieldatei vom cadwoman sind die Blockreferenzen aber allesamt aufgelöst, bis auf die erkannten Schalter, die dann auch innerhalb der aufgelösten anderen Referenzen erkannt wurden. Ich glaube nicht, dass cadwoman das selbst gemacht hat.

Zitat:

---

Original erstellt von cadffm:
@Archtools
>"und dass ähnliche Geometrien innerhalb anderer Blockreferenzen nicht verändert werden sollen?"
Identische Geometrie in Blöcken werden ignoriert, wenn es noch weitere Geometrie in dem Block gibt.

---

Nein, das ist in cadwoman's Beispiel auch anders. Da wurden andere Blockreferenzen aufgelöst, und die innerhalb der Geometrie erkannten Schalter wurden konvertiert, obwohl andere Geometrie enthalten war.

[Diese Nachricht wurde von archtools am 16. Mai. 2025 editiert.]

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

---

>>"In der Beispieldatei vom cadwoman sind die Blockreferenzen aber allesamt aufgelöst,"
Das kommt von ihm, nicht von BCONVERT/BSEARCH

>>" bis auf die erkannten Schalter," (und die Test "3FachStecjdose" auf gefrorenem Layer)
>>"die dann auch innerhalb der aufgelösten anderen Referenzen erkannt wurden."

>>"Nein, das ist in cadwomen's Beispiel auch anders. Da wurden andere Blockreferenzen aufgelöst, und die innerhalb der Geometrie erkannten Schalter wurden konvertiert, obwohl andere Geometrie enthalten war."
Klarer Fall, denn nach dem Auflösen durch den Benutzer, gab es ja keine Blöcke mehr, nur noch Objekthaufen.

Daher sollte man bei Objekthaufen als Quelle darüber nachdenken in welcher Reihenfolge man das angeht.
Hätte er einfach die bestehende Blockreferenz genommen, dann wäre das nicht passiert - oder einfach zuerst den Kreuzschalter machen..

>>"Ich glaube nicht, dass cadwomen das selbst gemacht hat."
Darfst cadwoman alles glauben und zugestehen   

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

---

Zitat:

---

Original erstellt von cadffm:
Hätte er einfach die bestehende Blockreferenz genommen, dann wäre das nicht passiert.

>>"Ich glaube nicht, dass cadwomen das selbst gemacht hat."
Darfst cadwoman alles glauben und zugestehen   

---

Ich glaube zwar, dass "er" eine "sie" ist, aber OK. Es ist halt schlecht, wenn man ein Beispiel für das Wirken von BKONVERT zeigen will, bei dem man aber die Hälfte der Arbeit selbst gemacht hat.

Ich hab' schon viele Jahre kein AutoCAD mehr, und kann das deshalb nicht selbst prüfen.

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

---

Zitat:

---

Original erstellt von cadffm:
@cadwomen
   Jetzt warten wir auf denjenigen der das Beispiel zum vierten Mal macht

---

Aller guter Dinge sind 3

sorry , not sorry , bin bei "euerer" Überlegung nach Darstellung und Pixel die Objekte neu zu generieren "ausgestiegen und das nur getestet wie "gut" ADSK das mit dem Boardmittel macht.

das nehmen der unterschiedlich benamten Blöcke hat bei mir nicht funktioniert

Und ja man darf MIR alles zutraun  

cu cw

------------------
Also ich finde Unities gut ... und andere sicher auch
------------------------------------------------
cadwomen™
Plant ist nur die Spitze des Berges der da treibt ?

[Diese Nachricht wurde von cadwomen am 16. Mai. 2025 editiert.]

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

---

@cadwomen
>>"nur getestet wie "gut" ADSK das mit dem Boardmittel macht"
Genau das haben wir, C4DP4P57 & Ich (siehe mit ACAD umgesetzte DWG Beispiel oben) auch gemacht.

>"das nehmen der unterschiedlich benamten Blöcke hat bei mir nicht funktioniert"
Dann hast du irgendein Problem gehabt, Anwenderfehler oder sonstiges, das geht.
Kannst es gerne noch einmal mit Archtools DWG testen und wenn es wieder nicht funktioniert,
PM mit Beschreibung des "geht nicht" an mich.

Wenn man aber Blockreferenzen auswählt und ACAD einen neuen Block bauen lassen möchte, statt diese eine Blockreferenz zunächst aufzulösen,
dann sollte man im Nachgang ein Tool laufen lassen um die verschachtelten Blockreferenzen zu löschen.
(Das entspricht ja meinem Beispiel, auf das Auflösen der Quellgeometrie, wie auch das auflösen von verschachtelten Referenzen, hatte ich wie beschrieben verzichtet.)

- - -

@Archtools
>>"Ich glaube zwar, dass "er" eine "sie" ist, aber OK."
Darfst cadwoman alles glauben und zugestehen

>>" Es ist halt schlecht, wenn man ein Beispiel für das Wirken von BKONVERT zeigen will, bei dem man aber die Hälfte der Arbeit selbst gemacht hat."
Ich habe dir die Arbeitsweise aufgezeigt, mache das hier aber gerne noch einmal in kurzform,
auf dein Beispiel (bestehende Blockreferenzen) ausgerichtet:

Der Schnellschuss, ACAD erstellt neue Blöcke:
1.Quellgeometrie wählen
2.einmal das "Suchergebnis" bestätigen
3.Blocknamen eingeben
fertig, Blockbasispunkt = Geometriezentrum
Dann hat man allerdings BlockInBlock generiert, ein "explodenestedblocks" wäre dann anzuraten.

Der Schnellschuss, ACAD erstellt neue Blöcke, etwas langsamer:
1.Quellgeometrie wählen
2.einmal das "Suchergebnis" bestätigen
3.Blocknamen eingeben
4.Blockbasispunkt angeben
fertig
Dann hat man allerdings BlockInBlock generiert, ein "explodenestedblocks" wäre dann anzuraten.

Anstatt "explodenestedblocks" könnte man auch vor dem Wählen der Quellgeometrie, die Blockreferenz auflösen,
aber dann müßte man das ja für jedes Symbol machen- ein "explodenestedblocks"-Tool ist da einfach sinniger im Nachgang.

Jetzt noch der negative Fall:
Der Lahmarsch: ACAD soll Geometrie gegen vorhandene Blöcke tauschen:
1.Quellgeometrie wählen
2.einmal das "Suchergebnis" bestätigen
3.Ziel Block angeben
4.Die Ausrichtung bestimmen (zum speien! deswegen wäre es gut wenn die Quellgeometrie bereits die Ausrichtung aufzeigt, welche auch dein Zielblock bei Drehung0 hat)

Dieser "Ausrichten" Dialog ist grausam und zu 99% unnötig - Adesk hätte das leicht automatisch erledigen können.
Vielleicht hänge ich später mal einen Screenshot an.

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