Batch editing drawings

Wiebe van der Worp

First of all, I am pleasantly surprised that BricsCAD 14 processes way over 1000 drawings per hour in a slow computing environment and when corrupted drawings were removed, 30.000 start-process-close cycles did not result in any crash. I thought it might be helpful to others to write the experience down on http://wiki.nedcad.nl/Bulk_Editing_Drawings.

However, I have a question. What is a smart approach to further decrease start-up times? As far as I know, headless - like with AutoCAD - is not an option, so a start without GUI elements seems the next step. Is it as simple as stripping default.cui? With a /p and /l switch? Ideas welcome?

Roy Klein Gebbinck

Apart from using a .bat file there are at least two other ways to control a batch process in BricsCAD: you can use a script or rely on Lisp code only.

Using a script file (.scr) for the batch process is probably the most common approach. It should be much faster than using a .bat file. My BKG_Batch application uses this method.

BricsCAD also has the unique feature that Lisp code can start in one drawing and continue in the next. This makes it possible to handle a batch process without a temporary .bat or .scr file. This method, most likely the fastest of the three, is however not 100% reliable when dealing with big drawings and time-consuming processes.

Wiebe van der Worp

Roy, a few days ago I tried it with one big script and fed BricsCAD 10 000+ files. It stalled after 10. So I reduced the set to 2 500 and then 900. Still stalling. So I gave up that path.

Curious after your post, I just tested 400 files this way and it did not stall indeed. So I gave the system 6GB more RAM and tried it with 1 000 files but it stalled again.

I guess it is save to say that using a script is okay for a maximum of a few hundred files. If one needs to process more, a batch file is the way to go. 10 000 in one night sleep is not bad in that case ;-)

It was also tempting to split the drawings and start multiple batch files simultaneously. I assigned four CPU cores and added batch files. With two batch files, speed almost doubled and process is stable. With three or four batch processes, things go south. Still just a bit more than one second per drawing.

Roy Klein Gebbinck

I do not experience those restrictions using a script. Even on an old (>10 yrs) underpowered (512MB RAM) machine I have no issue processing a large (2000) set of drawings using a script. Mind you the script is only used to open the drawings, load one or more Lisp files (which take care of all the rest), and save the drawings.

Wiebe van der Worp

You triggered me to not give up... Summary: It works! At least for a few thousand drawings tested so far.

First BricsCAD seemed crashed, "BricsCAD not responding", but it turned out a lot was done in the background without updating the screen anymore. Sometimes a crash, sometimes not. About the things that went wrong:

At last, the following construction was used, an example of a script line:

._open "drawingname.dwg" (acad-push-dbmod) (load "todo.lsp") todo.lsp (acad-pop-dbmod) ._close

Turns out (acad-pop-dbmod) was buggy in v14, v16 but works in v17, just in time (and thanks developers!)

I think that is the main reason it did no go as planned. About dbmod, if 0 no save queries are triggered. To be complete and as test for command line:

._QSAVE < sets DBMOD to 0
(getvar "dbmod") < returns thus 0
(acad-push-dbmod) < returns always T and stores DBMOD value for (acad-pop-dbmod)
(getvar "dbmod") < nothing changed, still 0
(command "._circle" "0,0" "1" "._erase" "_l" "") < drawing changed, DBMOD changed
(getvar "dbmod") < Now value 1
(acad-pop-dbmod) < returns T, but more important, turns DBMOD to stored value 0 as done by (acad-push-dbmod)
(getvar "dbmod") < returns 0 in v17 and not 0 in v16 and prior
._CLOSE < Should not ask for "Save changes" and works fine in v17. Returns unexpected pop ups in v16 and prior.

Roy Klein Gebbinck

@Wiebe van der Worp:
Again I cannot confirm the issue you report. Your scenario works just fine in V14 and V16. Maybe you have an application installed that is causing the unexpected behavior you are seeing.

Torsten Moses

Dear Wiebe, Dear Roy,

maybe this here explains & helps ...

Up to & incl. V16, when a drawing contains fields, and those fields were initially evaluated/updated by opening the dwg (FIELDEVAL), then the drawing was "modified" with DBMOD > 0 ...
this was fixed with V17, field evaluation during load-time does no longer set DBMOD > 0, so it might explain the difference.

But Roy is correct as well - it is not a safe logic to always expect that the drawing remains unchanged, during your own processing ...
too many possibilities, that some (other) code hooks in, and causes DBMOD > 0.

for Wiebe :
here is a way to bypass that difference - you can use this in your script file :
(if (> (getvar "DBMOD") 0) (command "_close" "_no") (command "_close"))

or
(command "_close")
(if (> (getvar "DBMOD") 0) (command "_no"))

this should work fine on all versions ...
many greetings !

Roy Klein Gebbinck

Thanks for the clarification Torsten.

Another way to close without saving:
(vla-close (vla-get-activedocument (vlax-get-acad-object)) :vlax-false)

Wiebe van der Worp

Roy, Torsten, appreciate your time and efforts, thanks.
I've updated the text. And did put a link to Roy's solution in there because of its ease of use.