ENGINEERING CASE STUDY

One-Line Packet Automation

Every order entering the engineering system produced a complete drawing packet (one-line diagram, cover sheet, spec sheet, title block), generated automatically from SAP configuration data and routed by order type. I modernized the system that did it, then built the same capability from scratch for a second business unit.

Role

Lead Software Engineer

Organization

Rockwell Automation

Stack

C# · AutoLISP · AutoCAD · SAP XML

Scope

Two business units

  • ~ 100 / week

    Packets generated unattended, about 5,200 a year

  • ~1,000 hrs

    Drafting and data entry saved per year (estimate)

  • 0

    Transcription errors, eliminated by construction

The problem

Every order moving through the engineering system needed a drawing packet before it could reach the plant. Producing one meant opening AutoCAD, reading the order's configuration, choosing the correct one-line block, placing it on a title block template, keying in the order data by hand, assembling a cover sheet and spec sheet around it, exporting the result, and combining the pieces into a single document.

None of that is design work. It is transcription: reading values out of one system and re-entering them into another, correctly, for every order, forever. It consumed drafting capacity that should have gone to engineered work, and every manual re-keying was a chance to put the wrong configuration in front of a plant.

We worked directly with the engineering program managers to find where the real cost sat. They knew their own pain points; the job was to understand them well enough to build around them rather than guess from a requirements document.

What existed, and what I changed

A first-generation version was already running when I arrived: the SAP integration, a Visual Basic service on a VM, and a set of basic AutoLISP macros. The instinct behind it was sound (orchestration outside the drawing, drawing work inside it) but the pieces were loosely connected and hard to extend. I brought them together into one system and rebuilt the parts that limited it:

  • Migrated the service layer from Visual Basic to C#, restructured around proper object-oriented boundaries so new order types and sheet formats could be added without touching unrelated code.

  • Rewrote the SAP XML ingestion to handle configuration data more reliably.

  • Extended the AutoLISP command set to cover more of the drawing assembly.

  • Connected the stages into a single unattended pipeline, end to end.

01 SOURCE02 ORCHESTRATE03 DRAW04 ASSEMBLE05 ROUTE · CTO05 ROUTE · ETO SAPC# serviceAutoLISPPDF packetPlantEng. manager Order configas XMLVM · parse,drive, exportInside AutoCADblock + titleCover, spec,one-line · stitchNo human stepFlagged for review
Order configuration leaves SAP as XML. A C# service drives AutoLISP inside AutoCAD to assemble the drawing; the packet is routed by order type.


  1. Configuration data for each order arrives from SAP as XML and is parsed into the values the drawing needs.

  2. The correct one-line block is selected from the library based on that configuration.

  3. The block is placed on the title block template; title block fields are populated from the order data rather than typed.

  4. A cover sheet and spec sheet are generated and assembled around the drawing.

  5. The assembly is exported to PDF and stitched into a single packet.

  6. The packet is routed by order type: configure-to-order goes directly to the plant; engineer-to-order is flagged and passed to engineering managers.

The architecture

The split between the two languages is what makes this work. AutoLISP belongs inside the drawing (block selection, geometry placement, title block attributes) because that is where that work lives. It is the wrong tool for orchestration, file handling, XML parsing, and running unattended against a queue of orders.

Custom AutoLISP functions handle placement and drawing manipulation. A C# service on a VM parses the SAP configuration, decides what the packet needs, drives those functions, and handles PDF export, stitching and routing. Moving that layer onto proper object-oriented structure is what turned a working script collection into something a second team could adopt, and what lets it run headless against every order.

The routing logic

Configure-to-order products are fully determined by the configuration, so their packets went straight to the plant with no human step. Engineer-to-order products need judgment, so those were flagged and surfaced to engineering managers along with a generated starting point. The automation did not try to replace the engineering decision. It removed the transcription around it.

Then again, from the ground up

After the first business unit was running, I rebuilt the same capability for a second one, starting from its own products, configuration data and drawing standards rather than copying the first implementation across. Inheriting a system proves you can read someone else's design. Building it again where none of the specifics carried over proves you understood the pattern underneath.

Result

Roughly 100 orders per week, about 5,200 a year, running unattended against the order queue. Internal estimates put the saving at around 1,000 hours annually, about twelve minutes per packet. That figure is an estimate; once the manual process no longer exists, there is nothing left to measure against. Transcription errors between SAP and the released drawing were eliminated by construction. That one isn't an estimate.

What this demonstrates

  • CAD automation across the full stack: AutoLISP inside the drawing, C# driving it from outside, unattended in production.

  • Legacy modernization without downtime: migrating a live VB service to C# while it kept producing drawings.

  • ERP integration: SAP configuration as the source of truth.

  • Business-logic routing: the system knows which orders need an engineer.

  • Replication across business units: rebuilt from the ground up for different products and standards.

  • Requirements from the people with the problem: built with the program managers who felt the pain.

Hiring for CAD automation or internal tools?