How to Debug an AutoLISP Plotting Routine
A practical debugging method for plotting routines: reduce the batch, expose the current Layout and device, and verify one output stage at a time.
Main idea: Debug plotting automation by shrinking the problem until one command, one Layout and one output device remain.
Best use: Routines that work on some Layouts or computers but fail on others.
Start with the manual workflow
Reproduce the same plot manually before blaming the code. If the manual Page Setup is already broken, the routine may only be exposing a standards problem.
Before automating a production workflow, review AutoCAD Crashes When Plotting or Publishing, AutoCAD Batch Publish Stops or Fails: Troubleshooting Guide, and Plot Preview Is Correct but Printed Output Is Wrong.
Build the automation in small layers
Step 1 — Reduce to one Layout
Where: The first failing Layout
Do this: Run only the smallest command that reproduces the issue.
Check: The failure is repeatable.
Step 2 — Print the inputs
Where: Command line
Do this: Report Layout name, ConfigName, StyleSheet, paper/media and output path before plotting.
Check: You can compare the failing setup with a working one.
Step 3 — Separate change from plot
Where: Two test commands
Do this: First change the property; then inspect it; only then plot.
Check: You know which operation fails.
Step 4 — Catch errors without hiding them
Where: AutoLISP error handling
Do this: Use vl-catch-all-apply or a local *error* handler and report the message.
Check: The user sees the real failure instead of only ‘nothing happened’.
Step 5 — Restore environment values
Where: BACKGROUNDPLOT and active Layout
Do this: Save important state before the routine and restore it on normal exit and errors.
Check: Debugging does not leave AutoCAD in a different state.
Build a diagnostic version before you build a smarter version
When a routine fails, temporarily make it more talkative. Before each plot, print the drawing name, Layout name, output path, PC3 and paper/media value. After each plot, report success or the actual caught error. This can reveal a missing PC3 or a single odd Layout in seconds.
Do not “fix” the problem by adding automatic retries until you know what is failing. A retry can hide a standards problem and create a batch that appears successful even though some sheets used different settings.
What the code should control
- Command-line reporting
- vl-catch-all-apply
- Local *error* handler
- BACKGROUNDPLOT restore
- Active Layout restore
What you should deliberately leave manual at first
Do not add retries, automatic SAVE or file deletion while the underlying cause is unknown.
Failure modes to design for
- The routine swallows every error message.
- It fails only because the target PDF already exists.
- A PC3 or CTB is missing from one workstation.
- The active Layout is not restored after an aborted batch.
When this becomes a production tool
A mature routine should fail loudly but safely: identify the item that failed, leave existing files untouched, restore important AutoCAD state and let the user decide what to do next.
Official Autodesk references
Frequently asked questions
Why does a plotting routine work on one computer only?
PC3 files, printer drivers, CTB/STB search paths and trusted code paths are workstation-dependent. Compare environment as well as the DWG.
Should my error handler save the drawing automatically?
Usually not. During debugging, restoring state and preserving the user’s unsaved work is safer than forcing a save.
What is the fastest test for a driver problem?
Compare the same Layout with a local AutoCAD PDF PC3. If that works and the physical device fails, the device/driver path becomes a stronger suspect.
Explore more in AutoLISP Plotting & PDF Automation.