AD转OrCAD完整实操指南：原理图迁移、封装修复与踩坑速查

做硬件的老哥们应该都遇到过这种尴尬：手头有一套完整的Altium Designer工程，原理图、封装、网络表调得明明白白，结果客户或者合作工厂那边只认OrCAD Capture，要么就是公司并购、部门整合，整个团队从AD切到Cadence平台，图纸必须跟着搬过去。硬着头皮手动重画一遍？原理图动辄几百个器件、几十页图纸，真要重新画，工期和出错率都受不了。我自己从AD转向OrCAD的时候，最开始也以为“另存为一下就行”，结果导出来的文件在企业微信里发了不下十个版本，每一次打开都是新惊喜，不是器件变白板，就是封装属性全部丢失，后来静下心把整个转换链路摸了一遍，才算是真正跑通。

这篇保姆级教程就基于我实际操刀完成的多个AD转OrCAD项目，把转换前的准备、软件里的每一步操作、转换后图纸的二次重构、以及我这一路踩过的大部分坑一次性讲透。内容偏向实战，适合因为工作原因必须从AD迁移到OrCAD的硬件工程师，也适合正在交接别人AD图纸的Layout工程师参考。你放心跟着一步步做，不用懂太深的理论，也能把图纸平稳搬到OrCAD里继续干活。

1. 转换前的准备——比动手更重要的是想清楚

1.1 先搞清楚AD和OrCAD在底层思路上有什么不同

很多人在转换失败后第一反应是“工具不行”，其实根源在于两款软件对原理图的组织方式根本不是一个逻辑。

Altium Designer里，原理图是一个独立文件（.SchDoc），工程文件（.PrjPcb）只是把这些图纸、PCB文件、库文件“装”在一起的一个壳。图纸与图纸之间的连接关系，靠的是网络标号（Net Label）、端口（Port）和图纸符号（Sheet Symbol）来约定。你单独拷走一张SchDoc，里面的元件编号、网络名都还是完整的。

OrCAD Capture这边走的是另一个路子。它的核心文件是设计文件（.dsn），工程文件（.opj）负责引用.dsn和各个库。更重要的是，OrCAD对“元件”这个概念的颗粒度分得很细——一个器件在原理图里是符号（Symbol），在PCB里是封装（Footprint），两者通过元件属性里的PCB Footprint字段关联。而AD里的封装名写在元件属性的Footprint字段里，这个字段名都不一样，转换时如果映射规则处理不好，封装信息就丢了。

理解了这一点，你就能明白为什么AD直出OrCAD的.dsn后会有一堆奇奇怪怪的毛病——不是文件坏了，是AD在导出时用了一套自己的映射规则，把Footprint映射成了OrCAD的PCB Footprint，但很多自定义属性、特殊字符、端口连接关系没法100%还原。所以转换前别急着点保存，先心里有个底：转换不是“翻译”，而是一次有损搬迁，后续重构是必须的，不是可选的。

1.2 转换前的“三查三备”清单

我在接到转换任务时，无论客户催得多急，都会先压住节奏做一遍检查和备份。这套“三查三备”帮我把后面返工的时间省掉了至少一半。

三查是查什么：

• 查工程状态：在AD里打开工程后先Compile（编译）一遍，把所有的ERC错误和警告清零。带错转换是灾难性的，一个悬空引脚在AD里只是警告，导到OrCAD里可能直接导致整个网络短接或丢失。
• 查元件库依赖：看原理图里用了哪些库文件，这些库是否都存在本地。AD在导出.dsn时会把原理图上用到的符号打包进去，但如果你用了特殊字体、嵌入对象或者非标准符号，库缺失就会导致导出后器件显示成方框加问号。
• 查特殊对象：原理图里有没有使用AD独有的容器（Container）、器件参数表（Parameter Set）、或者带公式的属性。这几类对象在OrCAD里根本没有对应概念，导出时会静默丢弃，如果你不知情，后面生产时才发现少了参数，就很麻烦。

三备是备份什么：

• 备份整个AD工程文件夹，不是只备份原理图，而是把库、输出文件、工程配置全量复制一份。
• 导出前生成一份PDF原理图存档，方便转换后逐页核对网络连接和器件位号。
• 记录一份BOM（Bill of Materials），最好包含Comment、Footprint、Quantity这几个列，这是转换后人工核对的依据。

注意：不建议在多人同时编辑的共享工程上直接转换。我遇到过同事的AD工程开了协同编辑，我导出时正好他在另一边改原理图，结果生成的.dsn打开后某几页图纸的元件编号全部乱掉。转换前务必确保工程在单机、无占用环境下操作。

2. 保姆级转换步骤——从AD工程到OrCAD的完整路径

2.1 在AD侧完成另存为，拿到一个靠谱的.dsn文件

AD官方提供了两种思路来导出OrCAD格式，一种是“Save Copy As”（另存为），另一种是“File > Export > Export to OrCAD Capture”。两者生成的东西本质相同，但我长时间用下来，印象里Save Copy As的稳定性更好些，建议你优先用这个。

具体操作流程：

1. 在AD中打开你要转换的原理图工程，确认当前打开的是工程文件（.PrjPcb），而不是单独打开的某一张SchDoc。如果你只打开了单张图纸，导出时就只会导出这一页，其他页不会进去。
2. 执行菜单栏的 File > Save Copy As。
3. 在弹出的保存类型下拉菜单里，选择 “OrCAD Capture Design (*.dsn)”，注意别选成OrCAD PCB Design格式，那个是给PCB用的。
4. 保存后会弹出一个选项对话框，里面有几个关键选项。不同的AD版本界面稍有差异，但核心选项是是否包含Off-Sheet连接符、是否包含参数、是否需要将AD的网络标签转换为OrCAD的全局网络等。我的习惯是全选包含，至于转换后的网络标签风格，一般默认即可，后面再调整。
5. 点击OK，AD会开始转换，时间长短看图纸规模，一般几十页的工程也就一两分钟。

整个过程看起来很简单，但有几个细节我后来才摸透：

• AD导出的.dsn文件是自带版本信息的。OrCAD的Capture CIS版本如果比AD生成时的版本旧，会提示无法打开。如果你手里的OrCAD是16.x这种老版本，AD那边导出前最好在Preferences里把兼容版本调低，或者接受后让OrCAD高版本打开再另存为低版本。
• 导出时AD会生成一个.log日志文件，和.dsn放在同一个目录。这个日志很多人不看，但其实里面记录了所有被删除、被替换、映射失败的对象清单。转换完成后第一件事，不是急着打开.dsn，而是先打开这个日志文件扫一眼，看看有没有你关心的信息丢失。

2.2 OrCAD侧打开.dsn，重建工程结构

有了.dsn文件之后，在OrCAD Capture里的操作就简单多了：

1. 打开OrCAD Capture CIS，菜单 File > Open > Design，找到刚才导出的.dsn文件并打开。
2. 第一次打开时，OrCAD会提示你工程中引用的元件库路径找不到，让你手动指定库路径，或者选择忽略。这里建议先点忽略，因为AD导出时已经把符号打包进了.dsn，绝大多数情况下图纸主体是可以正常显示的，库路径问题留到后面整理时再处理。
3. 打开后你会在项目导航栏里看到这个设计，正常情况下原理图页、元器件、网络都在，但此时还不是一个完整的OrCAD工程，因为缺少.opj工程文件和对应的Outputs配置。建议你 File > Save As，把.dsn连同当前环境保存成一个新的.opj工程，这样后续做DRC、生成网表、转PCB都有个容器管理。

这一步做完，你处在“能看”的状态，但离“能用”还有距离。我经常跟同事打比方：这一步相当于你把一屋子东西从旧家搬到了新家，东西是都运到了，但全堆在客厅，还没归位到各个房间，也没接上水电。接下来要做的事情，就是一件件归位。

2.3 转换后的第一轮快速检查清单

在动手做深度重构之前，我会先用半小时快速过一遍下面这几项，确认有没有致命问题：

• 页数是否完整：查看.dsn里的原理图页数，和原AD工程的实际页数是否一致。不一致的话，问题大概率出在AD侧导出时只导出当前打开的图纸。
• 元件数量是否一致：用OrCAD的Tools > Bill of Materials生成一份当前BOM，统计器件种类和总数，和AD的BOM对照。数量差异超过几个，说明有元件在转换中丢失，不能往下走。
• 网络名是否完整：把OrCAD里的网络表导出来看一眼（Tools > Generate Netlist，选其他格式也行，或者直接在Design Rules Check里跑一遍），确认关键的电源轨、地网络、总线网络都在。
• 元件编号是否规律：快速翻几页图纸，看R1、C1、U1这类位号是否连续、有规律。如果出现诸如R1、R1A、R?_1这类的怪名字，说明转换过程中发生了位号冲突，需要批量处理。

如果第一轮检查全部通过，恭喜你，这个工程可以进入下一阶段——重构和修正。如果发现数量对不上，别慌，别反复重新导出，先把AD侧的日志和OrCAD里的错误列表对照排查。大多数丢失问题的根源是AD里使用了OrCAD无法表达的对象，日志里会记录得非常清楚。

3. 转换后的图纸重构——别指望一次到位

3.1 元件属性、位号和封装的二次整理

AD导出到OrCAD后，最让我抓狂的是元件属性七零八落。AD的元件属性是自由扩展的，你想要什么字段就加什么字段，比如耐压值、精度、厂家料号、替代料号，随便加。而OrCAD里每个元件有默认的Attribute（属性），虽然有自定义属性能力，但转换时AD的每个参数具体映射到哪个Attribute，取决于AD导出的映射规则。

我实际转换中发现，AD里的Comment、Value、Description这几个常用字段通常能带过去，但更多自定义字段，比如厂商料号（Manufacturer Part Number）、替代型号（Alternate Part Number），经常被合并成一个值，或者直接消失。

整理属性的实操方法：

1. 在OrCAD里全选某一页的所有元件，右键 > Edit Properties，打开属性编辑器。
2. 检查每一列的属性值是否合理。重点看三个字段：Part Reference（位号）、Value（参数值）、PCB Footprint（封装）。这三个字段直接决定后续做网表、Layout能不能正常走。
3. 对于丢失的PCB Footprint，单独筛选出来重新填。如果AD那边有完整的封装名清单，建议在AD里导出一份封装对照表（用报表功能），照着填比在OrCAD里猜靠谱一百倍。
4. 自定义属性如果数量多，可以在OrCAD里用Edit Properties的批量操作，给整页器件统一添加属性列，再逐行填值。也可以用Capture的TCL脚本批量处理，但那个门槛高一些，新手用属性编辑器就足够了。

位号问题我多说一句：AD允许多个Part共用一个位号再通过"L"区分（比如U1A、U1B），但OrCAD里这属于异构元件（Heterogeneous Part），转换时如果没有正确处理，可能出现U1A、U1B、U1C全部变成独立的U1_1、U1_2、U1_3，或者干脆全部丢失只留一个。遇到这种问题，建议拆成独立元件重新添加，别在坏图上修修补补，越修越乱。

3.2 电源符号、off-page连接符和层次图纸关系的修正

这部分是AD转OrCAD时最容易出“隐性错误”的地方。什么叫隐性错误？就是图纸看起来完全正常，电阻电容都在，网络标号也显示着，但一跑DRC或者生成网表，出来的连接关系和原图完全不是一回事。根源都在电源符号和跨页连接符上。

AD的电源符号分为两类：一类是全局电源符号（VCC、GND这类），一类是局部电源符号（比如不同电源域用的VCC_3V3、VCC_5V）。AD里它们本质上对应同一个网络名的Net Label。OrCAD的电源符号也是靠网络名驱动的，名字对得上就能连上。

但我在转换时遇到过一个诡异情况：AD里用斜杠分的电源网络名（比如5V/3.3这种带“/”的），转换后OrCAD里的网络名被改写了，斜杠变成下划线或其他形式，导致电源网络和原设计不一致。这类问题肉眼非常难发现，最好的排查方式是：在OrCAD里跑一遍Tools > Design Rules Check，然后逐条看ERC报告里的电源相关告警。

off-page连接符的问题更麻烦。AD用的是Off Sheet Connector，OrCAD用的是Off-Page Connector。两者外形和功能类似，但AD导出到一个地方后，OrCAD这边往往不认为它们属于同一网络，除非具备相同的Net Name。处理办法是：在OrCAD里全局搜索网络，把所有连接到off-page连接符上的Net拉出来核对一遍，确保每一页同名的off-page网络确实是相连的。

如果你原工程用了AD的层次设计（Hierarchical Design），也就是有顶层Sheet Symbol、底层子图、端口互联的那种，转换后层级关系大概率会丢。AD导出时会把层次结构“拍平”，全部展开成平铺图纸，Sheet Symbol对应的子图关系不再存在。这个属于软性损失，不会导致网络错误，但对后续维护和阅读很不友好。要修复的话，只能手动在OrCAD里重新创建层次块（Hierarchical Block），没有更好的办法。所以如果你这个AD工程是个超复杂的层次设计，转换前我建议你先认真评估是否有必要转，还是直接在OrCAD里重新组织结构更划算。

3.3 网络名合规性处理与总线处理

AD对网络名的容忍度比OrCAD大很多。你可以在AD里给网络起一个类似“NET$12-34”的名字，也能起一个带空格、带括号、带中文的名字，AD全都认。但OrCAD对网络命名的限制更严格，一些特殊字符在导入网表、生成PCB时会导致无法解析。

我在多次转换中总结出来的“非法字符黑名单”至少包括这几类：空格、斜杠（/）、反斜杠（\）、中括号（[ ]）、括号（()）、星号（*）、问号（?）。这些符号在AD里可能相安无事，但到了OrCAD里轻则报错，重则网络表导出失败。

处理策略很简单也很笨：批量替换。在OrCAD的全局编辑功能里，把含特殊字符的网络名统一替换成下划线。但要注意，替换不能只改一半，比如你把网络名里的斜杠改成了下划线，结果另一个网络本来就含下划线，两个网络就撞车了。正确做法是先导出所有网络名清单，人工或半自动地列出冲突关系，确保替换后的名字全局唯一，再动手改。

总线的处理也是一个高频痛点。AD的总线定义方式是“BUS_NAME[0..7]”这种段范围，OrCAD也支持类似定义，但两者的总线标签书写方式不能完全混用。转换后总线经常出现的一个问题是：总线内的信号名和对应的网络标号不匹配。比如AD里总线标了DA[0..7]，但里面单线标的是D0、D1，这种在图上看不出来，但DRC会报Bus Mismatch。我的习惯是转换后在OrCAD里专门跑一次Bus相关的DRC检查，把所有总线不匹配的报错全部清掉，再进行下一步。

4. 常见错误修复速查——踩过的坑都在这

4.1 错误类型总览与速查表

下面这张表是我的个人经验汇总，按出现频率排的序。不能说100%覆盖所有AD转OrCAD的坑，但覆盖了我和我身边同事遇到过的大部分情况。

4.2 高发问题排查实录

挑两个我实际处理过很多次的问题，把排查思路写细一点。

第一个是“封装属性丢失”。遇到这个问题时，别急着在OrCAD里一个一个器件补封装，那是效率最低的方式。我的做法是这样的：先在AD里打开原工程，用Reports > Bill of Materials导出一份带Footprint列的BOM，整理成Excel；再在OrCAD里用Tools > Bill of Materials导出一份当前BOM；两个文件都按位号排序，用VLOOKUP之类的公式把AD的Footprint匹配到OrCAD的对应位号上，生成一份“位号-封装”对照表；最后在OrCAD的属性编辑器里全选元件，选择Load From File之类的方式批量导入。整个过程大概十几分钟，比手工填两三百个封装快得多，还不会填错。

第二个是“DRC报大量ERC错误”。这是最让人头大的问题，因为错误数量一多，你就会本能地觉得“这图没救了”。实际上，我在处理时发现，很多ERC错误是同类问题在不同器件上的重复出现。你可以先按错误类型分组，不要一条一条看。比如电源网络提示“No driving source”这种，往往是因为电源符号的属性是普通的Passive而不是Power，把这个类型统一修好，错误数量能直接消掉一大半。修正方法：在OrCAD里过滤出这类电源符号，在元件属性里把Pin Type或Power属性改正确，或者干脆删除后重新从电源符号库放置。

4.3 哪些“错误”其实可以忽略

不是所有报警都要处理。转换初期我对DRC报告里每一行都较真，结果浪费了许多时间在一些“假错误”上。比如：

• 某些未连接引脚的提示（Unconnected Pin），如果原AD工程里本来就是预留不用的NC引脚，转换后OrCAD报Unconnected是正常的，不需要管。
• 元器件Value属性为空的提示，如果你原图中就没有Value，这个报错可以忽略。
• 自定义属性不一致的提示，比如AD里的某些参数被合并了，只要不影响BOM和网表，可以先放着。

我的经验是：高优先级的错误必须清零，但有些提示类警告可以记录在案、标记为已知问题，留到后续版本处理。一个转换工程是否合格，核心标准是：生成的网表与AD原图导出的网表在器件、网络、连接关系上一致性大于等于99%，而不是DRC告警数量为零。

5. 转换完成后的收尾工作——验证与归档

5.1 用网表和PCB做二次验证

图纸在电脑里看着再好，也不如让工具用一遍来得实在。我会建议你在完成上面的重构之后，在OrCAD里做一次完整的闭环验证：

1. 先生成网表：Tools > Generate Netlist，选择Allegro格式（如果后级PCB工具是Allegro）或者其他目标格式。
2. 然后新建一个空的Allegro PCB Designer工程，导入这个网表。
3. 在导入报告里查看有没有器件缺失、网络缺失、封装找不到的报错。如果在PCB导入这一步能全部通过，那这个原理图基本可以放心交付了。

这个方法比单纯在原理图上看DRC报告靠谱得多，因为网表导入PCB的过程会暴露出所有底层数据问题——封装路径、引脚映射、元件类型冲突等等。我甚至建议在大型工程转换后，哪怕你不做PCB设计，也走一遍这个流程去验证数据完整性。

5.2 交付时的文件规范与团队协作建议

转换完并验证通过的工程，交付时我一般会整理成固定的目录结构，方便团队里的同事使用：

• 根目录放.opj工程文件，命名遵循公司内部项目规范，最好包含项目代号和版本号。
• 二级目录按库、原理图、输出文件、备份这四类归档。库目录放.dsn用到的所有符号库和封装库副本，不要沿用原始路径，避免同事电脑上路径不对打不开。
• 输出文件目录放生成好的PDF原理图、BOM、网表，这些是给生产、采购、硬件评审用的。
• 备份目录放转换过程中所有中间文件，包括最初的AD工程包、第一次导出的.dsn、日志文件。

团队协作时还有个容易被忽略的点：OrCAD工程里的.dsn是二进制格式，不像AD可以用文本对比工具检查变更。所以每次修改后建议顺手另存一个版本号，别只在一个文件里反复改。真出了问题，还能回滚。另外，如果团队内有人还保留着AD环境，尽量让他们用AD的工程做并行评审，两边对照着改，比单方面转来转去效率高得多。

写在最后的一点实操体会

把这一整套流程跑过几遍之后，我的体会是：AD转OrCAD这件事，技术上真的不复杂，复杂的是对数据完整性的敬畏心。每转一次，理论上都是一次有损搬迁，你每一次手工修正，其实都是在补全那些软件替你丢掉的“上下文”。所以与其等着转换完再手忙脚乱地修，不如转换前多花半小时把原工程的编译报错、属性规范、网络命名全部理干净，后面能省几倍的力气。

最后再分享一个我自己的习惯：每次做这一类转换，我都会在手机备忘录里记一份“踩坑笔记”，把这一次遇到的新问题、解决思路、花了多长时间写下来。行业里的工具版本一直在更新，今天的问题未必是明天的坑，但排查问题的思路是通用的。等你转了几个工程之后你也会发现，真正有价值的不只是那份.dsn，而是你手里越来越厚的那份translation checklist。祝你们迁移顺利，少加班。