Below is a typical message that is displayed after the purge is complete (total number of purged objects will vary). As a benchmark, I performed the purging process on a client’s file and it took 2 minutes 10 Seconds to clean. Once the DLL is loaded, type in DGNPURGE at the command line and press RETURN to purge out the objects causing file bloat. In summary, all that is required is replacing a file in the root of the application folder ( AcDgnLS.dbx) and then running AutoCAD and using the NETLOAD command to load a DLL ( DgnLsPurge.dll). Opening a case with the Autodesk support team confirmed this fact and at the time the case was open, the only strategies were the previously mentioned workaround using Civil 3D/Map 3D as well as two other alternatives, the first using DXFOUT/DXFIN and the second utilizing AutoCAD 2010.įortunately, as of August 2nd, 2013 the AutoCAD DGN hotfix has come out that specifically addresses this issue. While this at least revealed the problem, it still left me with no readily accessible tool to rid the drawing of these proxies. NET and all its derivative posts located at the end of the article. For an extensive understanding of the underlying purpose of these proxies, please read Kean Walmsley’s Through the Interface post named Purging unwanted DGN linestyle data from an AutoCAD drawing using.
Further research would later precisely target DGN LineStyles. The proxy warning targeted the missing application as AcDgnLS, which exposed that the offending objects likely came from Microstation (the tell being that Microstation files are designated with a DGN extension). Looking at the sample dialog window to the left you will see a very large number of proxies, approximately two hundred thousand, which would explain the excessive bloating seen in the file size. When examined, the dialog window finally gave us the lead we needed. It was through some extended dialog with the client that the next piece of the puzzle fell into place, namely the indication that when opening one of the affected drawings in an earlier version of AutoCAD (2010 to be exact), a proxy warning dialog window appeared.
#Autocad civil 3d 2013 not responding opening file license
This allowed me to assist our clients by cleaning one or two problematic drawings but did nothing to allow users to help themselves, mostly since this problem seemed to happen exclusively to our architectural clients who typically don’t have a license of either Civil 3D or Map 3D. This is usually my go-to step in fixing drawings and sure enough, going through this process reduced the file size tremendously. Using this feature one can define and execute queries related to objects in an existing drawing and then draw them in a new one. One of the benefits of being a long time Civil 3D user is knowing about some of the built-in Map 3D Features that enable users to attach an existing drawing to an empty file as a database. As I previously mentioned, I went through what I consider due diligence whenever troubleshooting an issue related to mysterious drawing behavior checking the number of scale lists ( SCALELISTEDIT), ensuring that there aren’t excessive registered applications ( REGAPPS), purging any unused styles ( -PURGE), and auditing the file for corruption ( AUDIT), however none of these methods resolved the bloat problem nor did they identify the source of the cause.
Examining a sample drawing that a client sent me, I noticed what appeared to be a small drawing with very little line work weighing in at 7.38MB. Identifying certain characteristics of a problem usually helps single out its cause, much like I imagine a doctor’s diagnosis would be based on a patient’s symptoms.
All this to say that I found myself asking what could be possibly done to not only identify this problem but resolve it once and for all? Even blocking out the drawing into a clean template made no difference. Purging did nothing to reduce the file size. At a cursory glance, there seemed to be nothing wrong with these drawings. One such recent issue involved multiple clients all of whom exhibited the same mysterious crisis: having a user base working with DWG files that kept getting increasingly larger. While I generally find my own motivations in life aligned with Isaac Asimov’s quote which declares that “ the true delight is in the finding out rather than in the knowing“, there have been times troubleshooting certain issues where I found myself wishing I just knew what was wrong.
0 kommentar(er)
