前阵子接了个活儿客户发来一套用Altium DesignerAD画的原理图指名要转成Orcad Capture 能打开、能继续编辑的 DSN 文件。项目页数不算多二十来页但里面电源符号、多Part器件、总线这类“AD味”很浓的东西不少。本想着“另存为DSN”几分钟搞定结果光是属性重构和网络核对就搭进去一个多礼拜。这类AD原理图转Orcad的需求在硬件圈里太常见了——客户指定工具链、公司统一换Cadence流程、或者后端要用Allegro做PCB都躲不开这场“跨工具链迁移”。但很多人对转换难度的认知有严重偏差以为文件后缀变了就完事大吉其实AD和Orcad背后是完全不同的两套数据模型、库体系、属性规则。DSN文件只是把图形和部分属性搬了个家真正的工作量在搬家之后的“重新安家”。这篇文章我就把整套AD转Orcad的实操路径、踩坑点、验证方法一次性讲透。内容包括怎么判断自己需要哪种转换程度、AD导出DSN的完整流程、进入Orcad后的属性重构和位号整理、一个真实的网络分裂事故排查过程以及DSN走不通时的网表级替代方案。文末还会给一个我一直在用的“网表Diff验收法”用数据而不是肉眼来确认转换结果。1. 先别急着导出找准你的转换场景很多人打开AD就是File - Save Copy As - 选DSN导出失败或者打开乱套了才回头想“我到底要什么”。我的习惯是动手前先花十分钟回答一个问题这次转换的终点是哪里1.1 交付场景对方只是要“能打开、能改字”这类需求最多。客户或者方案公司要求交付Orcad格式本质上是希望他能用自己熟悉的工具审图、标注、简单修改。这时候DSN转过去如果符号不完美、属性有偏差问题不大只要电路拓扑对得上、位号能辨别、网络名基本可读就能交差。这种情况下我一般不会去做太重的属性迁移重点放在保证连通性和可读性。转换后实测能打开页面数量对齐位号前后一致就足够了。我见过不少同事在交付场景里花大量时间去抠封装映射完全没必要。1.2 迁移场景后续要在Orcad/Allegro体系里继续画板这种才是真正的硬骨头。不是把原理图“展示”在Orcad里而是后面还要做DRC、导网表、进Allegro布局布线。那你就不能只求看得懂必须做到每个元件符号都有规范的属性位号、Value、PCB Footprint电源网络没有分裂、误合并位号与客户原图一致符号的Pin名和Pin号与数据手册一致。到了这个程度DSN转换只是打了个底后面要动的手术非常多。可能三页的板子都能折腾你大半天。1.3 网表交换场景原理图文件都不用转还有一种容易被忽略的情况其实根本不需要在Orcad里重建原理图。比如AD的整套设计已经完成只是后端想用Allegro做PCB验证或者协同那核心交付物就是网表而不是原理图源文件。AD可以导出多种通用网表格式Protel 2.0、EDIF、甚至直接给Allegro用的格式Allegro那边导进去就能开始布局。但这里有个前置条件原理图和PCB的封装名体系必须先对齐不然网表导过去一堆footprint mismatch后端一样干瞪眼。提示先判断“交付可读文件”还是“继续做设计”能帮你省掉一大半的无用功。这个判断做错了后面所有步骤都是在错误方向上浪费时间。2. 主路径实操AD导出DSNOrcad打开确定要冲击完整DSN转换之后正式操作就开始了。核心路径就是AD把原理图另存为DSN文件Orcad Capture再把这个DSN打开。听起来简单但每个环节都有讲究。2.1 导出前的三个准备动作AD导出DSN之前我强烈建议先做三件小事这是无数次翻车换来的教训第一编译工程并清掉明显的DRC问题。在AD里用Project - Compile PCB Project先编译一遍。为什么要这一步因为DSN导出过程本质上是对原理图做一次“重新打包”如果原图里存在未连接引脚、重复位号、非法网络名这类隐患打包时经常会异常终止或者静默丢数据。先把工程编译干净导出成功率会明显提升。第二检查特殊字符。AD的网络名和元件位号允许存在一些特殊字符但DT这些字符在DSN格式里并不都合法。我遇到最多的是网络名带空格、带“/”的情况。导出前全局搜一遍把疑似有问题的网络名改掉。第三备份原工程。听起来像废话但AD在导出DSN时偶尔会因为自身Bug造成工程文件损坏。我现在导出前一定会把.PrjPCB整个目录打个压缩包。别嫌多余一次毁图就够你记住这个习惯。2.2 导出DSN时版本怎么选AD中执行File - Save Copy As保存类型里选择 Design SchematicDSN随后会弹出对话框让你选择目标版本。我自己的经验是如果对方明确告诉你Orcad/Capture的版本就按那个版本选如果不知道对方版本优先选较低的DSN版本。低版本兼容性更宽虽然会丢失一些高版本特性但至少能打开AD在导出DSN对话框里一般会提供一个“Exporting DSN”的日志路径导出完成后务必打开看一眼有没有警告信息。关于版本选择我多说一句我见过有人为了“保留更多信息”选了最新版本去导出结果对方Orcad版本偏老打开直接报错最后还是回来用低版本重新导。导出DSN的版本号越低越可能丢失总线定义、层级结构等信息版本越高信息保留越完整但对方工具版本也必须匹配。这是一对矛盾按实际下游环境来取舍。2.3 Orcad打开后的三步检查Orcad Capture里File - Open - Design选中DSN文件。首次打开通常会有一大堆警告弹窗不用全记但有几件事必须去核实第一步数页面。AD工程有多少个SheetOrcad打开后就应该有多少个Schematic Page。页面丢失是转换失败的常见表现而且经常不报错你不数一遍很容易漏。第二步扫一眼Title Block。AD的图纸边框和标题栏是画在原理图里的图形对象转换后不会变成Orcad的Title Block属性。也就是说你在AD里辛苦填的项目名、图号、设计者信息导入Orcad之后基本全部丢失。这一点不是Bug是两套工具机制不同只能接受。第三步抽查网络名和位号。挑几个关键页面看看Net Alias有没有被追加奇怪的后缀位号有没有变成R1_1这种格式。我后面会专门讲怎么批量清理这一步只是为了建立初步印象。如果第一次打开DSN后你发现页面总数对不上或者同页面内容错位严重 建议回到AD重新导一次而不是在Orcad里手动修。 % 手动修不仅工作量巨大而且很容易引入“看起来对但实际上不对”的假连接。3. 转完只是开始属性重构才是大头DSN文件被Orcad打开从文件层面说转换是成功了。但从“能用”的角度很多时候只完成了30%左右的工作量。接下来要面对的是AD世界和Orcad世界的“文化差异”问题。3.1 符号库和封装库从AD体系到OLB/AllegroAD的元件体系是集成库IntLib原理图符号和PCB封装被打包在一起。Orcad这边是另一套思路Capture用OLB文件存原理图符号Allegro用独立的Pad、Dra文件存PCB封装两者通过元件的“PCB Footprint”字符串属性关联。DSN转换后Orcad会自动生成一个库文件里面装着从DSN里解出来的原理图符号。但这些符号的信息精简得可怜往往只有图形、引脚和少数属性。你需要在Orcad里做这样几件事逐个或批量核对元件的Value属性AD里的Comment导过来后经常放在“Unknown”之类的属性里需要映射到Orcad能识别的位置把AD的Footprint属性内容批量转换/改写成Allegro封装名。比如原来写的是“LQFP-48_7x7mm”Allegro那边对应封装可能叫“QFP48P9X9X2-48N”两边命名体系完全不一样必须建立映射关系有条件的情况下尽量把整理好的符号存回自己的OLB库不要一直依赖DSN带出来的临时库。临时库在后续项目里没法复用一旦重新生成DSN又得再整理一遍。3.2 位号与BOM信息后缀清理与Annotate的取舍位号问题是AD转Orcad的重灾区。由于两边的位号解释规则不同转换后经常出现如下几种情况位号被追加后缀如R1变成R1_1、U2变成U2_1多Part器件的子部分被拆散成独立符号位号显示为U1A、U1B但原图里根本没有这种写法无位号的辅助符号如测试点、安装孔被自动分配了位号。如果对方要求保留原图位号你绝对不能一上来就点Tools - Annotate。Annotate是按Orcad自己的规则重排位号跑完以后位号确实整齐了但跟原图和BOM就对不上了。正确做法是先手动改后缀优先处理带_1这种明显的后缀然后导出BOM和原AD的BOM做一次位号集合比对确认两边位号完全一致再去考虑是否需要用Annotate微调。3.3 电源网络、多Part器件、总线三类AD特性的退化这几类是在转换中“受伤最重”的对象我把常见的退化情况整理成了一张表方便你转换后快速对照排查AD中的特性转换到DSN后的常见问题Orcad中的处理建议电源网络Power Port同名Power Port和Net Label可能分裂成两个网络导出网表后做网络集合Diff统一合并分裂网络多Part器件一个元件拆成多个独立符号位号后缀丢失人工确认Part编号必要时重新命名总线Bus总线成员关系丢失网络名展开后排序错乱检查总线标签和网络标签确认每个成员位都对得上差分对差分对标识丢失或变成普通网络对照原图重新定义差分对属性层级原理图子图间连接关系可能被拍平层次信息丢失评估是否必须保留层次必要时重新组织图纸结构表格里列的都是高频问题。尤其是电源网络分裂这个事我在第4章会用一个完整事故来演示它到底有多隐蔽。4. 一个真实的转换事故网络分裂排查实录说了这么多理论用一个实际案例把排查过程完整串一遍你会对“格式转换造成的数据失真”理解更深。这是我给一个外部团队做转换评审时遇到的情况。4.1 症状DRC正常但布线后电源区一团乱对方把一个板子从AD转DSN再在Orcad里整理完送进Allegro。原理图画得看不出问题DRC检查也通过了网表导进Allegro也没什么大报错。但布线工程师在布电源时发现问题板上明明只有一个3.3V电源域铺铜的时候却总有两块“互不相认”的区域而且有些去耦电容的引脚根本没跟主电源连通。4.2 排查从原理图到网表Diff的完整链路我接手后没有直接打开原理图去看而是先做了两件事让原AD工程导出一份网表再从转换后的Orcad里导出一份网表然后把两份网表里所有网络名列出来做集合对比。结果很快就找到了异常AD原图里有一个网络叫“3.3V”下面挂着30多个引脚Orcad转换后的网表里出现了两个网络“3.3V”和“3.3V_1”3.3V下少了大概10个引脚这10个引脚全部跑到了3.3V_1下面。从比值看就是有将近三分之一的电源引脚被“分家”了。肉眼看原理图根本看不出来——屏幕上到处都是“3.3V”的标签谁会去数它们是不是同一个网络4.3 根因Power Port与Net Label的“同名不同命”再往深处查发现问题出在AD原图的画法上原图里3.3V这个网络一部分引脚是通过Power Port符号连接的另一部分是通过Net Label文本标注的。在AD自己的数据体系里同名Power Port和同名Net Label会被合并到同一个网络但导出的DSN进入Orcad后Orcad对这两类对象采用的是不同处理规则Power Port生成了一个全局网络Net Label则生成了局部网络结果同名网络硬生生被拆成了两个。这里有个很难防的点不是每个版本的AD导出都会这样有时候Power Port和Net Label能正确合并有时候就分裂跟原图放置顺序似乎还有关系。所以唯一的稳妥做法不是“画图注意”而是“转换后必须做网络级验证”。4.4 处理与预防处理方式倒不复杂。在Orcad里全局搜索3.3V_1把该网络上的引脚全部重新关联到3.3V网络然后删掉空网络。但要特别留意一个风险如果3.3V_1里恰好包含某些本来应该独立的信号网这个合并操作就会“张冠李戴”。所以合并前务必逐个核对引脚别用全局替换一把梭。经过这次事故我建立了一条铁律任何完整的AD转Orcad项目必须做网表级Diff验收不能在原理图上看一眼就叫“转完了”。这也是我写第6章的由来。5. 方案B网表级传递与“重绘校验”打法不是所有项目都值得死磕DSN转换。有些场景下DSN转出来的结果乱七八糟、修复成本远高于重新画图这时候转换策略就得换思路了。5.1 网表级传递AD导出通用网表给Allegro如果后续流程是Allegro布线而原理图本身不要求保留Orcad格式那最省事的路径就是直接走网表AD里Design - Netlist - Protel 2.0格式导出.net网表或者按需导出EDIF格式。Allegro那边通过第三方网表导入功能把网表和封装映射关系准备好就能开始布局布线。这种方式的局限也很明显网表只是“连接关系清单”它不包含原理图的图形布局、页面组织、标注信息。后续如果你想再改原理图还得回到ADOrcad这边只负责生产。如果公司流程要求原理图也必须沉淀在Orcad这条路就走不通。5.2 重绘法把PDF当底图在Orcad里重建原理图这个方案听起来笨但在某些场合反而是最靠谱的。操作方式用AD把每页原理图高质量导出PDF或者导出SVG/DXF作为底图在Orcad里按相同页面大小新建Schematic把PDF放在底层作为衬底Place Image然后照着底图在顶层放置元件符号、画连线、放网络标签一边重绘一边对照网表清单确保每个页面的连接关系没有遗漏完成后导出一份Orcad网表与原AD网表做Diff一致才算完工。说实话重绘法的工作量很大但对那些DSN转换后修复成本奇高的设计尤其是大量使用总线、层级、多Part器件的复杂设计重绘加上网表校验往往能控制在可预期的时间内。我见过有人在DSN转换结果上硬修了一个月修到崩溃最后推到重来反而一星期搞定。5.3 要不要花时间死磕DSN我的判断标准我的判断标准就三条供你参考原图是否“画得规矩”。如果原图用的是规范库、规范位号、规范网络命名转换后大概率比较干净值得修下游只是看图还是继续做设计。只看图DSN转成功就够要设计必须预留重构时间转换后的异常数量是否收敛。如果体检时发现电源网络分裂、位号后缀、页面丢失同时爆发而且没有规律这时候停止死磕DSN转用方案B。6. 网表Diff验收转换质量用数据说话落在纸面的原则说一百遍也不如一个具体工具来得实在。这一章我把自己一直在用的“网表Diff验收法”分享出来任何人都能照着搭一个。6.1 为什么视觉检查不够原理图是给人看的网表是给机器用的。视觉上“看起来连上了”和电学上“确实是同一个网络”是两种完全不同的可信度。DSN转换过程中发生的网络名篡改、引脚漂移等异常绝大多数在图纸上完全不可见只有把两边的网表数据摊开来对比才能发现。6.2 把两种网表归一化成“网络-引脚映射”再对比AD的Protel网表和Orcad的网表格式不一样不能直接比对原文件需要先归一化成统一的数据结构。我用的是最简单的模型——一个网络就是一个键对应的值是该网络上所有“元件位号-引脚号”组成的集合# 简化示例解析后的数据结构 networks { 3.3V: {(R1, 1), (C5, 2), (U2, 14)}, GND: {(R1, 2), (C5, 1), (U2, 7)}, }python不管原始网表长什么样我都先写脚本把它解析成这个结构然后做两类对比网络名集合对比哪些网络在AD里有而Orcad里没有哪些是Orcad这边多出来的每个网络的引脚集合对比两边同名的网络挂的引脚是否完全一致。下面是一个极简版的脚本思路实际使用时可以根据网表格式调整解析逻辑import re def parse_protel_netlist(file_path): nets {} with open(file_path, r, encodinggbk, errorsignore) as f: lines f.read().splitlines() i 0 while i len(lines): if lines[i].strip() [: # Protel网表用[]分隔网络 i 1 net_name lines[i].strip() pins set() i 1 while i len(lines) and lines[i].strip() ! ]: pin_ref lines[i].strip() if pin_ref: parts pin_ref.split(-) pins.add((parts[0], parts[1])) i 1 nets[net_name] pins i 1 return nets def compare_nets(ad_nets, orcad_nets): ad_keys set(ad_nets.keys()) orcad_keys set(orcad_nets.keys()) print(仅在AD网表中存在的网络:, ad_keys - orcad_keys) print(仅在Orcad网表中存在的网络:, orcad_keys - ad_keys) for net in (ad_keys orcad_keys): diff_left ad_nets[net] - orcad_nets[net] diff_right orcad_nets[net] - ad_nets[net] if diff_left or diff_right: print(f网络 {net} 引脚不一致) print(f AD中独有: {diff_left}) print(f Orcad中独有: {diff_right})这个脚本跑一遍比在原理图上盯一天都有效。我每次转完项目都会跑一次把差异清单打出来逐项确认“确实是我预期内的差异”再往下推进。6.3 常见差异信号矩阵用这套脚本跑多了之后不同差异的出现基本都有迹可循。下面这张矩阵是我自己总结的遇到同样现象可以直接按图索骥差异现象可能原因影响处理Orcad多出一个同名带后缀网络Power Port与Net Label分裂电流路径断裂、DRC盲区合并网络核对挂接引脚某个网络两边引脚数量不一致转换中个别引脚连接关系丢失电路开路回到原理图查该网络周边连接位号带_1等后缀位号字段解析差异BOM对不上批量改名并重新比对网络名中空格变成下划线非法字符自动替换网表可读性变差可能引发后端问题提前在AD阶段清理非法字符元件Value属性缺失属性映射不完整BOM缺料号按原AD工程补Value或重新映射这套矩阵没法覆盖所有情况但把常见项掌握住转换项目的成功率已经有了基本保障。注意网表Diff只能证明“连接关系一致”不能证明“画图质量一致”。原理图里的位号摆放、图纸布局、注释规范还是需要靠人来检查。工具负责兜底人的判断负责质量。现在我做AD转Orcad的项目早就不会在“另存为DSN”完成后就宣布收工了。固定动作变成导出DSN、打开体检、属性重构、导出网表、跑Diff、对照差异清单逐项销项。整个过程看着琐碎但每一道工序都在消灭一类“看着没事、实际会炸”的隐患。我个人在实操中最深的体会是EDA工具之间的格式转换本质上不是“翻译”而是“搬运重建”。搬运的是图形和部分属性重建的是网络含义和设计意图。认清这一点你就不会拿着一个DSN文件就天真地以为活干完了也不会在修复无望的死胡同里死磕太久。希望这套实战流程能帮你少走几趟弯路转完的图纸真正敢拿去画板、打样、投产。