August 2014

Sun Mon Tue Wed Thu Fri Sat
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            








« Sphere packing in AutoCAD: filling an arbitrary solid using .NET | Main | Dynamic .NET in AutoCAD 2013 »

February 27, 2012

The AutoCAD 2013 Core Console

In the first of this week’s posts on the new, developer-oriented features in AutoCAD 2013, we’re going to take a look at the AutoCAD Core Console. I predict that this one feature alone is going to be worth its weight in gold to many customers and developers.

Picture this: a stripped down version of AutoCAD – but only from a UI perspective – that can be executed from a standard Command Prompt. We’re talking about a version with almost all the capabilities of full AutoCAD – with the ability to load certain applications and execute scripts – but launches in a couple of seconds (if you have a slow machine :-) and is absolutely perfect for batch operations.

[Note: you can only run this executable on systems that have AutoCAD 2013 (or one of its verticals) installed – you shouldn’t expect to be able to run it elsewhere.]

AutoCAD 2013 Core Console

Regarding batch operations: the version of ScriptPro currently on Autodesk Labs has been pre-enabled to work with the Core Console: all you have to do is specify the path to the executable in the settings.

And as well as being good at performing a set of sequential operations, the Core Console is a great way to get process-level parallelism (that harnesses all those spare cores many of us now have): you can launch multiple instances of the executable to run concurrently (or – for that matter – simply launch one to implement a “background” version of a command that would otherwise hog the editor during a time-consuming operation).

Before we get into what it means to be able to load “certain” applications, let’s talk a little about the background to this tool. It was made possible by a multi-year architectural project known internally as The Big Split: to make AutoCAD truly – and sustainably – cross-platform, we needed a core component that could be compiled for multiple (for now that means two) platforms. The majority of AutoCAD’s capabilities – including the drawing canvas and graphics sub-system – would be contained “inside” (if you think about it in logical – rather than physical – terms) this component.

This component is AcCore.dll on the Windows platform. If you take a look at acad.exe for AutoCAD 2013, for instance, you’ll see it is now about 5.7 MB, with AcCore.dll weighing in at 13.4 MB. Compare this with AutoCAD 2012, where we had a monolithic acad.exe of 17.5 MB.

Subsetting out this core functionality means we can share a common codebase for this OS-independent set of functionality, and expose an appropriate UI to it for whichever platform we’re targetting. For AutoCAD for Windows, this means using some MFC, some WPF, etc., while for AutoCAD for Mac this means using Cocoa.

And for the simplest possible, command-line only UI, we have the 24 KB AcCoreConsole.exe.

So what kinds of application can be loaded into the Core Console? It can certainly load DBX modules – which are coded against ObjectDBX/RealDWG, which is a subset of the “core” capabilities – but it can also load CRX modules and .NET DLLs that have been coded against the new AcCoreMgd.dll (rather than AcMgd.dll).

You can think of CRX modules as ARX modules developed to run against the core functionality: many of your commands – especially if using the command-line and jigs for their user-input – can be ported to CRX modules (or their .NET equivalent). Ideally you’d then have the GUI integration alone in your ARX modules (or .NET DLLs using AcMgd.dll) which then call into the “core” implementations.

This would allow them to be loaded into the Core Console and even in other environments, moving forwards (watch this space for more on that :-).

You can also load AutoLISP files into the Core Console – just as you can execute scripts – you just need to be aware that certain (mostly GUI-oriented) capabilities will not be available to you.

Let’s now take a look at a very concrete use for this tool, along with some code to drive it.

A very common requirement is for some kind of server-resident process publishing DWFs or PDFs from DWGs. Balaji Ramamoorthy, from DevTech India, wrote an elegant batch script that can sit on a server and use the Core Console to generate PDFs from DWGs (actually it’s a couple of batch files and an AutoCAD script, but anyway).

The main batch file sits and watches a particular “in” folder (which would ideally be network-accessible to be of much use). If it’s empty, the batch file waits for 10 seconds before checking again (to avoid unnecessary thrashing). If there’s something in the folder, the main batch file calls a secondary batch file (GenPDF.bat) to process the file(s) and create the results in the “out” folder.

Here’s the main batch file:

:: AccoreConsoleDemo for AutoCAD 2013

 

::Make changes to these parameters as per requirement

SET ACCOREEXEPATH="C:\Program Files\Autodesk\AutoCAD 2013 - English\accoreconsole.exe"

SET DWGINDIR="C:\Temp\IN"

SET DWGOUTDIR="C:\Temp\OUT"

SET POLLINGTIME=10

 

echo off

 

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

IF NOT EXIST %DWGINDIR% MD %DWGINDIR%

IF NOT EXIST %DWGOUTDIR% MD %DWGOUTDIR%

cls

:LoopStart

 

SET PDFGENBATFILEPATH="%~dp0"

set PDFGENBATFILEPATH=%PDFGENBATFILEPATH:~1,-1%GenPDF.bat

 

for /f "delims=" %%a IN ('dir %DWGINDIR% /b *.dwg') do call "%PDFGENBATFILEPATH%" %ACCOREEXEPATH% %DWGINDIR% %DWGOUTDIR% "%%a"

timeout /t %POLLINGTIME% /NOBREAK

goto LoopStart

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

 

:End

Here’s the secondary batch file, GenPDF.bat:

SET ACCOREEXEPATH=%1

IF NOT EXIST "%ACCOREEXEPATH%" goto ACCOREEXENOTFOUND

 

SET DWGINPATH=%2

SET DWGOUTPATH=%3

SET DWGFILENAME=%4

 

set DWGFILENAME=%DWGFILENAME:~1,-1%

set DWGINPATH=%DWGINPATH:~1,-1%\%DWGFILENAME%

set DWGOUTPATH=%DWGOUTPATH:~1,-1%\%DWGFILENAME%

 

:: Create the PDF file path

SET PDFINPATH=%DWGINPATH:dwg=pdf%

SET PDFOUTPATH=%DWGOUTPATH:dwg=pdf%

 

:: Get the script file path

SET SCRIPTFILEPATH="%~dp0"

set SCRIPTFILEPATH=%SCRIPTFILEPATH:~1,-1%SamplePDFGenScript.scr

 

::Generate the PDF file

%ACCOREEXEPATH% /i "%DWGINPATH%" /s "%SCRIPTFILEPATH%" /l en-US

move "%DWGINPATH%" "%DWGOUTPATH%"

move "%PDFINPATH%" "%PDFOUTPATH%"

goto END

 

:ACCOREEXENOTFOUND

echo %ACCOREEXEPATH%

echo "Accoreconsole.exe path is incorrect."

goto END

 

:DRAWINGNOTFOUND

echo %DWGINPATH%

echo "Drawing file not found."

goto END

 

:END

Which in turn needs an AutoCAD script file, SamplePDFGenScript.scr:

(setq CurrDwgName (getvar "dwgname"))

(setq Fname (substr CurrDwgName 1 (- (strlen CurrDwgName) 4)))

(setq name (strcat (getvar "DWGPREFIX") Fname ".pdf"))

;Command:

FILEDIA

;Enter new value for FILEDIA <1>:

0

;Command:

-PLOT

;Detailed plot configuration? [Yes/No] <No>:

Yes

;Enter a layout name or [?] <Model>:

Model

;Enter an output device name or [?] <None>:

DWG To PDF.pc3

;Enter paper size or [?] <ANSI A (11.00 x 8.50 Inches)>:

ANSI A (11.00 x 8.50 Inches)

;Enter paper units [Inches/Millimeters] <Inches>:

Inches

;Enter drawing orientation [Portrait/Landscape] <Portrait>:

Landscape

;Plot upside down? [Yes/No] <No>:

No

;Enter plot area [Display/Extents/Limits/View/Window] <Display>:

Extents

;Enter plot scale (Plotted Inches=Drawing Units) or [Fit] <Fit>:

Fit

;Enter plot offset (x,y) or [Center] <0.00,0.00>:

 

;Plot with plot styles? [Yes/No] <Yes>:

Yes

;Enter plot style table name or [?] (enter . for none) <>:

.

;Plot with lineweights? [Yes/No] <Yes>:

Yes

;Enter shade plot setting [As displayed/legacy Wireframe/legacy Hidden/Visualstyles/Rendered] <As displayed>:

 

;Enter file name <C:\Work\solids-Model.pdf>:

!name

;Save changes to page setup? Or set shade plot quality? [Yes/No/Quality] <N>:

No

;Proceed with plot [Yes/No] <Y>:

Yes

;Command:

FILEDIA

;;;Enter new value for FILEDIA <1>:

1

In the next post we’ll take a look at another very interesting capability of AutoCAD 2013, Dynamic .NET.

blog comments powered by Disqus

Feed/Share

10 Random Posts