yoin

Reimer

Ik gebruik al bijna een jaar lang een revisiebestand welke ik steeds aanvul en in verschillende tekeningen als ondergrond gebruik. Nu open ik vanmorgen tekening X met daarin de revisie als ondergrond, nu ligt deze laatste op een totaal andere locatie dan bedoeld. Beide tekeningen zijn tekend in een gebied rond 202300,504000 maar mijn ondergrond ligt ineens rond 0,0.  Bij de laatste wijziging in de revisie heb ik tijdelijk een ander UCS gebruikt. Het 0,0-punt van dit UCS lijkt nu het insertionpoint van de ondergrond te zijn. Voor een xref is toch het World-0,0-punt altijd het insertionpoint?

Ik hoop dat ik zo duidelijk maak wat ik bedoel, heeft iemand een oorzaak/oplossing?

Reimer

EddyBeerke

Heb ik ook eens gehad.
Ik heb gezocht wat het probleem veroorzaakte en kwam bij Refedit uit.
De "Hoofdtekening" en de Xref hadden een andere schaal of een ander insertpoint.
Misschien moet je 't daar zoeken.
Civil3d 2026, Blender 4.x gebruiker
Gebruiker sinds AutoCAD R12

http://eddylucas.c1.biz/
https://www.google.com/maps/contrib/109381066561676463628/photos/

Indo_Jim

#2
Je hebt blijkbaar ooit je revisiebestand gemaakt in een tekening en weg geschreven als wblock.

Ik bedoel......

Tekening is 100 bij 100 (limits is (x,y) -50,50 bij 50,50)
Je tekent nu een revisiebestand afmeting 10 bij 10 (op (x,y) is 10,10 bij 20,20)
Je schrijft dit weg als wblock(revisiebestand.dwg) en je kies links onder als insertionpunt ((x,y) is 10,10)

Als je het blockje(revisiebestand.dwg) nu insert zal het netjes linksonder als insertionpoint hebben.

Nu open je het revisiebestand.dwg en je pas wat aan en saved deze gewoon weer........... afmeting 10 bij 10 (op (x,y) is 10,10 bij 20,20)  
Als je het blockje(revisiebestand) nu insert nog steeds netjes linksonder als insertionpoint.

Nu open je het weer revisiebestand.dwg en veranderd ucs en saved deze ........... afmeting blijft 10 bij 10 (op (x,y) is 10,10 bij 20,20)  
Als je het blockje(revisiebestand) nu insert zal je insertionpoint op 0,0 staan.

Om dit problemen voor te zijn maak ik altijd een wblock door eerst in de tekening een block te maken en deze als wblock weg te schrijven.

Groeten Jimmy
Praat geen poep,
want er is al genoeg schijt in de wereld.

Reimer

De beschreven mogelijke oorzaken komen me niet bekend voor. Beide tekeningen zijn als losse tekeningen opgezet en nooit als Wblock weggeschreven. Verder gebruik ik nooit limits. De tekeningen zijn beide in RD-coordinaten getekend. Ten opzichte van World liggen ze beide nog steeds in het gebied rond x=202300 en y=504000. De revisietekening heeft als xref nu ineens een insertionpoint gekregen dat vlakbij het punt 202300,504000 ligt. Dit vindt ik erg vreemd omdat een xref naar mijn idee altijd als insertionpoint het 0,0-punt in WUCS heeft. Of is het mogelijk om dit voor een xref anders op te geven.

Ook maak ik echt nooit gebruik van refedit op een xref. Vanuit de xrefmanager geef ik altijd OPEN en bewerk dan mijn xrefs.

Wanneer ik de revisietekening als xref in een nieuwe tekening voeg, dan blijft hij het onjuiste insertionpoint gebruiken. Heel vreemd.

Reimer.

bart

Het punt waarmee een xref wordt geinseerd in de hoofdtekening is o,o,o in de xref.

maar dat hoeft niet overeen te komen met 0,0,0 in de hoodt tekening het inserten in de hoofdtekening gebeurd op een door de gebruiker aangeduiden punt t.o.v. het dan geldende ingestelde ucs.

je kan een xref net als een block gewoon met move verplaatsen
Domme vragen bestaan niet.
Domme antwoorden wel.

m.vr. groet Bart

Reimer

Het antwoord is gegeven door De Grote boze Wolf, in een LISP onderwerp (http://www.cadsite.be/smf/index.php/topic,2682.msg13723.html#msg13723)
Er was een andere waarde ingesteld voor de variabele INSBASE. Ik heb nog nooit van deze variabele gehoord dus ik snap ook niet hoe deze veranderd kan zijn. Maar, ik ben heel blij dat het probleem opgelost is.

Ik had al geprobeerd om van mijn revisiebestand een Wblock te maken, hierbij bleef het probleem bestaan (INSBASE gaat gewoon mee).
Ik had ook al de gehele inhoud naar een nieuw bestand gecopieerd. Dit zorgde er echter voor dat de attributen van bijna alle blocken ### kregen. BATTMAN loste dit niet op. Hier had ik dus ook niets aan. (mijn rioleringsblocks hebben attributen BOB1 en BOB2, het 3e attribuut VERHANG trekt BOB1 en BOB2 van elkaar af en deelt deze door de dynamische lengte. Wanneer de link tussen deze attributen eenmaal verbroken is dan krijg ik deze niet meer hersteld.)

Groeten van een opgeluchte Reimer.

bart

@remier

in INSBASE worden gewoon de coordinaten opgelagen die je in te zien krijgt bij het plaatsen van een block/xref
als je hier dus een insertpoint invult wordt insbase aangepast en opgeslagen in de tekening
Domme vragen bestaan niet.
Domme antwoorden wel.

m.vr. groet Bart

Reimer

Bart, volgens mij moet het meer zijn dan dat. Ik heb net even een testje gedaan.
Ik heb 2 bestanden gemaakt, A en B, waarbij A als xref in B is geplaatst (op 0,0). Ik heb daarna in A INSBASE ingesteld op 10,10 en dit opgeslagen. Wanneer ik in B de xref reload verspringt deze direct over een afstand -10,-10. INSBASE maakt dus een "virtueel" insertionpoint.

Reimer

bart

Domme vragen bestaan niet.
Domme antwoorden wel.

m.vr. groet Bart

Joop

Als je een block aanmaakt moet je een insertionpoint aanwijzen.
Dit punt wordt dan opgeslagen in de block tekening en wel in de varibele INSBASE.
Indien je niet tevreden bent met het insertionpoint van het block kun je naderhand in het block bestand de varibele wijzigen.
Een xref werk bij het attachen hetzelfde als het inserten van een block.
Alleen de data van de xref wordt niet opgenomen in de "werk" tekening en van een block wel.

Bij een standaard tekening staat de INSBASE op 0,0,0 (default).
Wil je deze tekening als xref gebruiken maar dan wel standaard verschoven dan pas je de variabele aan, dus het basepoint van de xref..
Citeer
Type:  3D-point
Saved in:  Drawing
Initial value:  0.0000,0.0000,0.0000


Stores the insertion base point set by BASE, which gets expressed as a UCS coordinate for the current space.
Een gelovig volger van
"de Sacrale Kunst van Luiheid",
zijn leider "Lisp" en acoliet "Script".