我不止一次被人问到：S7-1200到底能不能拿来做多设备控制？尤其当现场既有伺服轴要精确配合，又有一堆老设备要走PROFIBUS DP总线的时候。我去年接手了一个食品包装产线改造项目，控制核心整体换成一台S7-1200，现场设备构成其实很典型：六台V90伺服负责分度、送料、压合、切断这些动作，旁边还有一整柜老旧的仪表、变频器和远程IO，总线走的还是DP。换句话说，新一代CPU不光要把V90伺服这条"新路"管好，还得把老设备那条"旧路"一起并进来协调干活。这正是我从FB284一路摸到DP通讯的真实原因，也是这篇文章想完整记录的东西：S7-1200在中小型设备上做多设备控制，到底能扛到什么程度，以及实际踩过的坑长什么样。
如果你正准备拿S7-1200做多轴伺服控制，或者项目里还混着老DP从站设备，这篇应该能帮你省掉不少弯路。全文按我实际推进的顺序来写：先把FB284的底层逻辑讲透，再讲多轴程序的组织方法，然后是DP并网的完整步骤，最后是现场排障的完整记录。每个环节我都尽量把"为什么这样做"讲清楚，而不是只丢给你一串步骤。
1. 先搞清楚FB284到底在替你干哪些活
1.1 V90的EPOS模式与SINA报文是怎么配合的
V90本身不是一台"傻驱动器"，它内部带EPOS（内部定位控制）功能。你可以把它理解成一个会自己规划位置和速度的智能模块：你告诉它目标位置、目标速度、加减速度，它会在内部完成位置斜坡和速度斜坡，然后闭环控制电机。对PLC来说，理想状态下只需要"下达命令，读回状态"就够了。
问题出在"下达命令"这件事上。V90通过PROFINET报文和PLC交换数据，报文里每个字、每个位都有严格的时序含义。比如控制字哪一位是"使能运行"，哪一位是"取消运行"，哪一位是"复位报警"；状态字哪一位代表"轴已经到达目标位置"，哪一位代表"正在运行中"。如果你直接在程序里用MOVE指令往输出区里拼报文，初期看起来也能动，但时间一长很容易出现报警来得莫名其妙、位置偶发丢失、启停不跟手等情况。根子就在于报文时序被PLC扫描周期打乱了——该先写的位还没写，该保持的信号又闪了一下。
FB284（也被称为SINA_POS）就是官方把这套报文时序封装好的标准功能块。你不用再记第几个字节第几位，程序里直接看到的是Enable、Position、Velocity、Mode这些"轴驾驶指令"。它内部按固定时序把控制字写进输出区，同时解析状态字，把实际位置、实际速度、故障码这些数据吐出来。换句话说，FB284是PLC侧和V90之间的"翻译官"。这是理解整个方案的关键，后面所有排查都离不开这条认知。
1.2 FB284的关键引脚：给新人画的"接线图"
FB284用起来有点像给人画一张端子接线图，很多初次接触的人一上来就晕，其实核心引脚就那几个。我实际项目中常用的引脚整理如下：
| 引脚 | 方向 | 作用 |
|---|---|---|
| Enable | IN | 轴使能信号，必须持续保持TRUE |
| Mode | IN | 运行模式选择，如绝对定位、相对定位 |
| Position | IN | 目标位置（按设定的单位体系） |
| Velocity | IN | 目标速度 |
| Acceleration / Deceleration | IN | 加速度 / 减速度 |
| CancelTraversing | IN | 取消当前运行命令 |
| AxisPos | OUT | 轴当前实际位置 |
| StatusWord | OUT | 状态字，含运行、使能、到位等位 |
| PosOK | OUT | 已到达目标位置窗口 |
| Error / ErrorID | OUT | 故障标志 / 故障代码 |
这里特别提醒三点。第一，Enable是电平信号，不是脉冲信号。很多新手第一次调轴时，给的是扫描周期内一闪而过的TRUE，轴当然不动；应该让Enable在正常运行期间一直保持TRUE，只有急停、故障、停止时才把它拉掉。第二，一条定位命令的触发条件是Position、Velocity、Mode这些给定值就绪后的一次上升沿，所以在HMI里改完目标位置后，通常用一个"启动"按钮的上升沿去触发功能块。第三，看状态不要只看Error，要看ErrorID。ErrorID是十六进制故障码，不同值对应不同原因，这是故障排查的第一入口。
2. 从一颗轴到六颗轴：多轴控制的组织方法与时序陷阱
2.1 用UDT统一管理轴数据，而不是每个轴建一堆DB
项目里六台伺服，最简单但也最不推荐的做法是一个轴建一个DB、每个DB里散落着目标位置、速度、状态。我当时没有这样干，而是先定义一个轴数据类型UDT，把一根轴需要的所有数据和状态都装进去：轴号、使能、模式、目标位置、目标速度、加减速、实际位置、运行状态、到位信号、故障码、命令触发位。然后直接在全局DB里声明一个该UDT的数组，六根轴就是arrAxis[0]到arrAxis[5]。
这样做的优势是肉眼可见的：HMI读写目标位置时，只需要操作数组元素；程序里加轴、减轴，只要修改数组长度和HMI画面；所有轴的状态在监控表里整整齐齐排在一起，排障时不用在几十个DB块里翻来翻去。调用FB284时，每根轴对应一个FB284实例，实例的输入输出直接跟数组元素绑定，结构上非常清晰。
下面是一段简化后的SCL调用示意。注意它只是为了展示数据组织的思路，实际项目中你还会把单位换算、数值限幅、抱闸控制都加在传参层：
// 轴0的调用示意 #fbAxis[0]( Enable := #axisData[0].Enable, Mode := #axisData[0].Mode, Position := #axisData[0].TargetPos * 1000, Velocity := #axisData[0].TargetVel, Acceleration := #axisData[0].Acc, Deceleration := #axisData[0].Dec, AxisPos => #axisData[0].ActPos, Error => #axisData[0].Error, ErrorID => #axisData[0].ErrorID, PosOK => #axisData[0].PosOK );这里再多说一句单位换算：V90在EPOS模式下，位置给定通常要按参考单位处理，项目中经常出现PLC端目标值以毫米为单位、而FB284里要乘一个参考系数再填给Position的情况。这个系数放哪个DB、由谁来维护，最好在项目一开始就定好，否则后面六个轴六种单位，调试到怀疑人生。
2.2 多轴同时启动丢步了？问题出在调用位置
第一次让六根轴"同时启动"时，我遇到了一个非常典型的怪毛病：六台伺服都收到启动命令，动作也都做了，但用位置曲线对比会发现，轴6比轴1晚启动了几毫秒。在动作快的设备上，这点时间足够造成产品错位。我当时第一反应是伺服参数不一致，查了一圈发现根子不在伺服，而在PLC的程序组织。
原因其实很简单：一开始我把六个FB284实例按顺序全部写在OB1里，而OB1里还塞了HMI操作、画面显示、产品计数这些逻辑，一个扫描周期可能跑十几毫秒。轴1的FB284在周期开头执行，轴6的FB284在周期末尾执行，两者之间天然隔了大半个扫描周期。命令上升沿到达伺服的时间不一样，启动自然就不一致。
解决办法是把所有轴的FB284调用统一挪到一个循环中断OB里，比如OB32，把周期设置成5ms或10ms。这样六个轴实例在同一个确定的时间片里连续执行，命令发出的时间差被压缩到毫秒级以内。注意循环中断OB里尽量只放和轴控制强相关的逻辑，不要塞一堆HMI处理进去，否则中断OB的运行时间会被拉长，一样引入抖动。另外，循环中断时间要和工艺要求匹配：太快会增加CPU负担，太慢又可能让位置斜坡更新不及时。
2.3 案例：某产线"六轴顺序进料"状态机怎么搭
多轴控制除了同时动作，更多时候是按顺序配合。我在那个包装产线上有一个典型的顺序流程：轴1把料推进来，等轴1到位；轴2压合，等轴2到位；轴3切断，全部到位后一起退回原点。这种需求用状态机来写最合适，比在OB1里堆一排if嵌套清晰得多。
一个最简单的实现思路是定义一个状态变量，用常量定义几个状态：空闲、轴1运行、轴2运行、轴3运行、回原点、完成。每个状态里只做一件事，满足条件后切换到下一状态。例如在轴1运行状态里，给轴1下发定位命令，一旦轴1的PosOK有效，就把状态切到轴2运行，同时给轴2下发命令。这里有个容易忽略的细节：状态切换时，"上一个轴"的使能信号要保持住，等所有轴都完成再统一释放；如果每个状态结束时就把对应的Enable拉掉，轴会立刻停下来，反而导致流程卡住。
这个状态机的核心逻辑用SCL写出来其实不长，但要特别注意"命令触发位"的处理——状态进入时给一次上升沿，状态保持时不重复触发。我在项目中把触发位和状态切换放在同一个网络里做，避免扫描周期内重复触发两次命令，这个问题是我在设备试运行阶段偶发"轴多走一次"后才定位到的。
3. DP通讯接入：老设备并网的关键几步
3.1 S7-1200要接PROFIBUS DP，先想清楚用哪种方案
S7-1200的CPU本体上只有PROFINET口，不带PROFIBUS DP接口，这是很多人一开始没意识到的坑。项目里那批老仪表和变频器全是DP从站，要把它们接到S7-1200上，常见的是加装CM1243-5 DP主站模块。这是一块插在S7-1200本体前面的通信模块，组态完成后由它承担DP主站功能，PLC程序通过I/O地址直接读写从站数据，使用体验和读写本地IO几乎一样。第三种方案是用PN转DP网关，但网关在实时性和诊断能力上不如专用模块，现场环境复杂时不推荐。
我当时的选型逻辑很直接：第一，CM1243-5是S7-1200平台的原生扩展模块，在TIA组态里直接能选，不需要额外的驱动库；第二，它支持诊断，从站掉站之后能在模块的诊断缓冲区里看到记录；第三，S7-1200整体体积小，现场电柜里省地方。如果你的DP从站数量少、距离近，网关方案也能用，但要做长时间连续生产运行，我建议优先考虑CM1243-5。
这里还有一个选型细节：CM1243-5模块的版本要和CPU固件兼容。我习惯在TIA里组态完成后先做一次模块版本比对，避免下载之后才报组态不匹配，那种问题很容易让人误判成硬件损坏。
3.2 从GSD组态到物理布线：容易翻车的细节
DP从站接入首先是组态。以一块典型的8DI/8DO远程IO从站为例，在TIA里先添加CM1243-5，然后在它的DP总线上导入从站的GSD文件，找到对应设备型号，配置从站地址，再把IO模块映射到PLC的I/Q地址区。这一步看似简单，但翻车点特别多，我把最容易踩的三个列出来。
第一，从站地址。DP从站地址要么通过设备上的拨码开关设置，要么通过软件设置，必须和TIA组态里填的地址完全一致。地址不一致时，从站会一直处于"等待主站"的状态，BF灯常亮，主站诊断报告"从站无响应"。第二，总线速率。CM1243-5和从站的波特率必须一致，通常组态时可以设置自动识别，但现场如果混有老设备，建议统一按最慢那台从站的速率来跑，避免高速下某台老从站跟不上。第三，终端电阻。PROFIBUS电缆两端必须有终端电阻，很多总线插头上自带拨动开关，总线两端拨到ON，中间节点全部OFF。现场掉站有一半以上是这个开关没拨对。
组态完成后，把从站的输入输出地址映射记下来，再去做程序。地址规划建议给每类从站留出整段区域，比如远程IO用IB100到IB110，变频器用IW200到IW210，这样后面程序里做数据采集和报警统计不会乱。这件事不复杂，但一旦前期没规划，后期维护要改地址就是牵一发动全身。
3.3 DP从站"闪断"了：一次现场掉站的排查记录
项目调试到第三天，出现了最恼人的问题：某个远程IO从站每隔一两个小时就掉站一次，BF灯亮一下，过几秒自己恢复。从站掉站意味着联锁信号瞬间丢失，虽然程序里做了信号保持，但这种闪断在生产上是绝对容忍不了的。我把排查过程完整记下来，大家可以照着这个顺序走。
第一步先看物理层。把总线两端的终端电阻开关重新拨了一遍，确认在ON；用万用表量DP电缆的A、B两根信号线，确认没有断线。第二步看接头。把现场几个DP插头的屏蔽层压接位置逐个拆开检查，发现有段电缆的屏蔽编织网在弯折处已经断裂，接触时好时坏。第三步看干扰。确认DP电缆所在线槽和动力电缆的并行距离，如果不满足安全间距，变频器干扰会直接导致闪断，需要强制分槽或者加屏蔽层。
最终定位到的原因很朴素：设备检修时有人把一个DP插头拆下来，装回去时螺丝没拧紧，屏蔽层虚接。设备静止时通讯正常，一震动就闪断，再震动又恢复。这次排查给我留下的经验是：DP闪断问题，先不要急着怀疑模块和程序，百分之九十的闪断都在物理层。排查顺序永远是从缆线、接头、终端电阻开始，再到地址和波特率，最后才怀疑模块本身。
4. 伺服控制与DP通讯的协同设计：程序架构与联锁
4.1 为什么建议把FB284放进循环中断OB，而不是OB1
前面提到多轴同时启动的一致性，已经把FB284放进循环中断OB的必要性讲了一半。但还有一个更重要的原因：V90通过PROFINET和PLC交换数据时，报文数据在PLC循环中不断刷新，FB284需要在尽量固定的时间间隔内完成一次完整的读写和时序处理。如果把它放在OB1里，OB1的循环时间会随程序量波动，遇到HMI大量数据刷新时，OB1循环时间从10ms跳到30ms，对位置斜坡和报文时序都有影响。
把FB284调用放到OB32之后，CPU会以固定周期执行这一段程序，运动控制的时序就有一个稳定节拍。我在OB32里只放三件事：六个轴的FB284调用、轴之间的联锁判断、DP从站关键输入信号的读取。HMI的数据处理、配方管理、报警历史这些全部留在OB1。这样OB32的运行时间很短很稳定，运动控制部分完全不受OB1波动影响。
有一点要提醒：循环中断OB的周期不是设得越小越好。FB284本身执行需要时间，V90那边报文交换也有周期限制，一般设5ms到10ms是比较稳妥的区间。设置过短会让CPU忙于刷中断，反而挤占OB1的执行时间；设置过长又体现不出固定节拍的优势。具体数值可以在调试时用CPU循环时间监控表来看，让OB32占用率控制在比较舒服的范围内。
4.2 通过DP信号做安全联锁：急停、门禁、气缸到位
DP并网不只是为了让PLC能读到老设备的数据，更关键的是把从站采集的DI信号变成整个系统的联锁条件。我的项目里，急停按钮、安全门开关、气缸到位信号全部通过DP远程IO站的DI模块接入，在程序里统一处理后再去控制伺服轴。
最简单的联锁逻辑是这样的：急停信号只要变False，就立刻把六根轴的Enable全部拉掉，同时对正在运行的轴发出CancelTraversing命令。这里又回到了第一章强调的时序问题——急停联锁必须放在OB32里、在FB284调用之前执行，而不是放在OB1里慢慢处理。如果急停信号进了PLC但排在OB1靠后的位置，紧急情况下多等一个扫描周期都是不可接受的。
另一个细节是气缸到位。很多设备是气缸和伺服轴交替动作的：气缸先顶到位，伺服再进给。气缸到位信号如果来自DP远程IO，读取时机要放在伺服启动命令的前一步，确认真读到了从False到True的上升沿再下发伺服命令。我在项目里就因为气缸到位信号和伺服启动命令在同一个扫描周期里先后执行，出现过一次误动作，后来通过在OB32里先把到位信号锁存一拍再判断，问题就解决了。
4.3 诊断体系：看ErrorID和看BF灯的分工
设备运行起来之后，维护人员最关心的是故障怎么查。我在项目里把故障诊断分成两条线：运动控制线看FB284的ErrorID，通讯线看CM1243-5的诊断状态和从站BF灯。
运动控制部分，程序里每个轴的ErrorID都会传到HMI报警画面，显示成"轴1故障：0x0301"这样的格式。这里特别建议：不要把ErrorID数值直接丢给现场电工。HMI报警里一定要配一段中文描述，比如"轴1：运行使能信号无效"。描述文本可以按FB284故障码表整理，把几条常见故障先写在报警里，后续碰到新的再补进去。现场电工反馈，这个"翻译"动作比任何培训都管用。
DP通讯部分，从站掉站不像伺服报警会自报家门，它更隐蔽。我在PLC里做了掉站次数统计：当从站诊断状态变化时，计数器加一，同时记录掉站时间和累计次数。这样即使从站后来恢复了，维护人员也能从HMI上看到"这台从站今天已经掉过三次"，比等它下次再掉要主动得多。实际运行下来，现场最认可的就是这两个功能：伺服报警能看到文字描述，DP掉站有次数统计。
5. 实测复盘：从单轴调通到全线跑起来的完整时间线
5.1 第一周：单轴调通，卡在"使能没有保持"
项目推进的第一个瓶颈完全在意料之外：一根轴怎么都动不起来。当时我检查了报文、检查了V90参数，都显示正常，但轴就是没有反应。后来把FB284调用语句放在监控表里逐位看，才发现Enable引脚给的是脉冲信号——程序里用的是置位线圈，扫描周期过了就复位，轴一直在"刚使能完又失能"的状态里。改成保持型使能之后，轴立刻顺了。
这个阶段建议大家从一根轴开始调，不要一开始就上六轴。单轴调通的要点其实就三个：确认V90设置了EPOS模式并断电重启；确认报文选对了；确认Enable保持为TRUE。三个都对了，轴基本就能按命令走了。同时把单位换算和加减速参数先粗略定下来，后面多轴调试时再细调。设备上电第一周，我每天的工作量基本就是反复做这几件事，顺手把每根轴的编码器方向、正负限位都确认了一遍。
5.2 第三周：六轴联调，处理了三个"看不见的问题"
六轴同时跑起来后，遇到了三个靠监控表很难直接发现的问题。第一个是抱闸时序：有几台轴带机械抱闸，程序里一开始简单地把抱闸输出和使能信号一起给，导致轴还在速度不为零的状态下就抱闸，电机咔咔响。后来改成根据实际速度判断，速度低于设定阈值再输出抱闸信号，问题消失。第二个是回零方式不统一：有些轴的绝对编码器没有校准过，每次上电后实际位置会漂，后来统一做了绝对编码器校准。第三个是报警复位上升沿冲突：复位某个轴报警时，复位信号刚好和执行中的命令上升沿撞在一起，会偶发报错；后来把复位信号单独锁存，不在运动执行期间触发。
这三个问题有一个共同特点：它们都不会直接让轴停下来或者报大红字，但会让设备在长时间运行中积累故障。处理完之后我把FB284的调用周期从10ms调到8ms，六轴动作的同步性又上了一个台阶。现在回想起来，第三周才是整个项目最烧脑的阶段，因为问题不是不存在，而是"看不见"。
5.3 最值的一条经验：先在调试台上把所有坑踩完
整个项目做下来，我最想分享的一条经验是：多设备控制项目的调试顺序，应该是单轴、单轴带DP、多轴、多轴带DP联锁、长时间老化，这个顺序不要跳。每到一个阶段，都把该阶段的报警记录和掉站记录留底，尤其是DP掉站次数和FB284的ErrorID，后面定位故障能省一半时间。
另外一个实际的小技巧是用TIA的监控表把每个轴的ErrorID、PosOK、实际速度、从站状态同时放在一屏里。调试时同时看六轴的数据，哪个轴先报故障、哪个轴的PosOK晚到位，一眼就能看出问题，比在程序里单步追变量高效得多。我后来在项目收尾阶段基本都是靠这一屏监控来判定问题的。老化试运行那几天，我每天到现场第一件事就是打开这一屏看记录，连续三天没有新增掉站记录，心才彻底放下来。
最后说点个人体会。我做完这个项目最大的感觉是：FB284封装了报文时序，但真正的坑从来不在功能块本身，而在你调用它的方式——使能保不保持、沿给没给对、调用周期稳不稳定、急停信号优先级够不够高。DP通讯看着像组态和地址的事，但现场掉站十次有八次是线缆、接头和终端电阻的问题。把这套思路理顺，S7-1200在中小型设备上做多设备控制完全没有问题。如果这篇里的某个坑刚好帮你省了一次现场加班，那这个记录就没白写。项目做完一年了，产线至今稳定运行，希望下次遇到更复杂的设备时，我还能把新的经验继续补进来。
