Error Autocad
Julia Dodoo
The loft itself works, but if I try to use polyline guides, it fails (with the error code 98037 - not that there's any way of telling what that means!). I've redrawn the guides three or four times in different ways, but they fail each time. I'm absolutely certain the guides intersect the profiles (although I've been wrong before!), but now they've taken error messages out of CAD 2018, tracking down the problem is nigh on impossible...
I've had a play with the paths and different ways of creating them - the weird looping path seems to be the result of joining a 2d polyline and a 3d polyline. I've attached another version of the file with one path I've re-drawn. This time, I've created the path as a polyline in two parts, to see if I could get half the shape to loft, but still no luck...
Went back to the original file and split the yellow profiles in half. This seemed to work for the part I lofted with guides. It doesn't seem to work all the pieces however. Is this intended to be symmetrical? Perhaps constructing a top and then a bottom in pieces might work better.
I tried repeating what you did and breaking the profiles into quarters, then lofting to create surfaces, but I can't even get it to do that! The lofting works, but any sort of guide line I use throws the same 98037 error.
...actually, despite my despairing of CAD's 3d abilities, I couldn't close the file for good and walk away without trying one last thing. My original guide lines running forward from the mid-section profile were formed from a straight line, a spline and then a tighter spline to get the required radius at the front of the object, all joined together. Although it changes the shape of the object slightly (the front radius is larger), a re-drew the guides with only one spline at the front instead of two and all the guides now work - I've attached a revised drawing.
So I have used the recover all command, -purge (regapps), -purge (all), and audit on both files A & B. I have even wblock both the files and the issue is temporarily fixed, but then it comes back within a matter of 15/30 mins. I must also add that whenever I Xref file B into the sheets it is making the saving process SUPER slow.
I am attaching files A & B to this post in hopes that someone can please help me. My best guess would be that there is a rogue block or symbol that gets purged but keeps coming back... I am on a deadline in an office that has no in-house CAD support, so this is kind of my last attempt at fixing this issue after having searched the forums with no luck finding a solution to the same issue I am having.
An overlaid xref does not load or bring with it any nested xrefs. For example, if you xref "A" into your parent drawing, which contains a nested xref, drawing "B", only drawing "A" will be referenced in. Drawing "B" will not be loaded into the parent drawing because it is a nested xref.
Attached xrefs, when referenced into a drawing, will include nested xrefs, which means if drawing "A" is referenced into your drawing and it has nested xrefs "B" and "C" in it, drawings "B" and "C" will be attached to the parent drawing along with drawing "A."
Hi, yes I have done both types of recover. I have to further test this, but so far someone in my office offered this method of cleaning/purging the file and no errors have come back (fingers crossed)...
"Open dwg file > do DXFOUT command > save as 2007dxf version > open the dxf file> do AUDIT and PURGE > resave back as dwg file > Done!
Sometime the number of XREF files and how it's xref in can slow down your files too. I would suggest running the DXF steps (above) in all your files, even the xref dwgs (if the file is greater then a few mb, it usually calls for a dxfout file clean up) and then check if all your XREF files can be xrefed in as overlay vs. attachments (for example, if the baseplan (walls and hatches) that we talked about is xref as an attachment into 5 drawings, CAD will circular reference when it's going back and forth to relink the same dwgs 5 times. and that can def. slow down production and saving time) Hope this helps."
Attachment - Tells AutoCAD to include other Xref attachments that are nested in the selected file.
Overlay - Tells AutoCAD to ignore other Xref attachments that are nested in the selected file. This avoids multiple attachments of other files and eliminates the possibility of circular references (referencing the current file into itself through another file).
Hi @Anonymous , I have a couple suggestions. In your drawing ground floor there are what look like shrubs on a layer named L_PLAN_TREES. They are a bunch of individual lines and there are over 80,000 of them. I would suggest creating a block and inserting it multiple times. Try using the command -purge and purging regapps, empty text objects and zero-length geometry. Also if the drawing saves slow try setting SAVEFIDELITY to 0 because you have annotative blocks in the drawings.
Quick question: The shrub blocks you talked about are already blocks. When I go inside the blocks I see the hundreds of lines you talk about. How do you recommend I simplify this geometry? I don't think I was able to follow your previous recommendation...
Maybe they are trees or something else but when I open the drawing you posted all the object shown in pic below are individual lines and not blocks. I was suggesting that could slow a drawing down having 80,000+ lines
I cannot tell wether it is a sudden problem or not. I use Autocad in this facility for about a year now on an occasional basis. Main CAD application here is CATIA so there is no IT based Autocad support other than installation and deinstallation. I interface with civil construction projects on our site which is a different world so I use Autocad to check architectural and utility drawings. Sometimes I return drawings with my own proposals and it just happens that for my current drawing working with block definitions is the way to go. And that's where I realized this fatal error issue for the first time. As far as I can tell, the fatal error is exclusively related to the "insert block" functions "recent blocks..." and "blocks from other drawings...".
Using the insert command at the command line gave me a slightly different unhandled exception error with a more detailed log (see file "unhandled exception log text. txt"). It looks like an handling problem between Autocad and Windows...
Background: I am running Autocad with two language packs on this computer: german and english. I prefere the english version since I "grew up" with it and don't know the german commands. For the fun of it I started the german version and voil: inserting blocks worked just fine w/o any error messages.
This is a clean install with no form of add-ons or personal lisp routines etc so I am 100% confident that this message is not linked to something I have added. The message comes up regardless of what the error trigger is, even something as simple as typing (alert 1) will throw this message out rather than the expected bad argument type: stringp 1.
I then changed my profile to plain AutoCAD, restarted CAD and tried triggering an error and this time I get the correct error message. So it seems that whatever is going on, it is related to something within the Architecture profile.
Has anybody else experienced this situation? I have tried on three machines (all running the same software setup) and each of them throws the same error when in the Architecture profile but not in the AutoCAD profile so I know it is not specific to just one machine.
happens on one paticular file which has objects from older versions of AutoCAD. No problems on newly created files. Also, the error is not confined to one user. When other users in the office open the same file, the error message is the same.
My MEP still gives this error when I have the MEP or Architecture profiles loaded. The only time I get the 'proper' error message is if I have the vanilla AutoCAD profile loaded - exactly the same as it was before applying the SP.
Has anyone found a solution to this yet? I can run an Express Tool once and then after that I'm getting the same error. For instance, I can run EXTRIM and it will work once, but not again. It will also stop all of my other Express Tools from working until I close and reopen the drawing.
It would appear that there is a problem with the way the *error* function is defined. That could be caused by a routine you run, if it improperly makes changes to error handling. Since many others (including me) are reporting this, I suspect that the default *error* function is either improperly defined or some out-of-the-box function is changing it and not resetting it correctly.
You can reset the *error* function to its proper default by typing in the following at the Command: (or saving it as a plain text file with an LSP extension, and then loading that file).
If you go with putting the *error* function redefinition in ACADDOC.lsp, and you have SECURELOAD set to 1, you will want to place ACADDOC.lsp in a folder that has been designated as a Trusted Path on the Files tab of the Options dialog, to avoid getting a nag dialog asking if you want to load the file with each drawing. If SECURELOAD is set to 2, you have to do that or the code will not load at all.
ff7609af8f