FlexSim发生器四种用法详解：从Source节点到条件触发式生成

每种仿真项目开场，几乎都躲不开那个拖着一个小三角箭头的图标——发生器（Source）。FlexSim里这个名字起得太朴素了，以至于很多人用了一两年都以为它只是个“按时扔东西出来的节点”。但真把模型做复杂后你会发现，发生器在不同场景下至少有四种完全不同的用法，每一种都对应一类建模需求，选错了轻则模型绕路，重则逻辑根本跑不通。

这篇文章就把这四种使用方法摊开讲：Source节点直接生成、Process Flow里的Source活动、全局表驱动的批量生成、以及条件触发式的按需发生。顺便把“entity卡死”“批量数量不对”“发生器不发东西”这些高频问题一并盘一遍。如果你是刚接触FlexSim的学生，或者工作中要拿它做产能分析、物流仿真的工程师，这篇应该能帮你少踩不少坑。

1. 先搞清楚：FlexSim里的“发生器”到底有几种形态

很多初学者会把“发生器”等同于工具栏里的那个Source节点，其实这只说对了一部分。从FlexSim 7.5以后，Process Flow（流程逻辑）大改版，Source以活动（Activity）的形式重新出现，能力和使用场景跟传统节点完全不同。加上FlexSim支持通过全局表驱动发生器参数、也支持通过消息或条件语句控制发生器的暂停与释放，实际项目中我会把“发生器”按用途拆成四种形态。

理解这个分类有个很实用的角度：节点式发生器是“定时定量往外吐”，流程式发生器是“跟着逻辑走”，数据驱动发生器是“照着订单来”，条件触发发生器是“看现场脸色干活”。四种形态底层用的都是同一个对象生成机制，但挂载的控制逻辑完全不同。

所以别再问“为什么我的发生器不按照想的来”——先想清楚你要的是哪一种“来法”。建模第一步不是拖节点，是定义生成策略。

2. 第一种用法：Source节点直接生成临时实体

这是FlexSim里最基础、最常用的一种用法。Source节点默认连接下游处理器或暂存区，按设置的到达间隔输出临时实体，比如工件、货物、人员、托盘，本质上就是一个“对象生产器”。

2.1 到达间隔、到达数量、到达时间表的区别

Source节点属性面板中，“到达间隔（Inter-Arrival Time）”和“到达数量（Quantity per Arrival）”是最容易混淆的两个参数。

我见过不少新手的模型，本意是每5分钟来一批货，一批10箱，结果把到达间隔设成5、把到达数量设成10，运行后模型却疯狂爆实体——因为他们没有意识到，Source默认的“到达时间间隔”是实体之间的间隔，不是“批与批之间的间隔”。

正确的理解方式：

• 到达间隔：每个实体之间的时间间隔。设为5分钟，意味着每隔5分钟产生第2个实体，再隔5分钟产生第3个，每轮都单独出现。
• 到达数量：每一次“到达”动作中同时生成的实体数量。如果同时设置到达间隔为5、到达数量为10，实际效果是每5分钟“吐”10个实体，然后这10个实体一次性涌向下游。
• 到达时间表（Arrival Schedule）：这是更精细的控制方式，可以按时间轴定义多组到达事件，每组独立设置时间、数量和实体类型。

项目实践中，如果只是做一个稳定的流入，我会优先用“到达间隔+到达数量”的组合；一旦涉及班次变化、午休停机、订单波动，直接用“到达时间表”最稳妥，因为它能把整个班次表写进去，不需要写额外逻辑。

2.2 实体类型的分配逻辑

当模型中有多个产品类型时，Source节点默认只能生成一种实体类型。要实现“按比例生成多种类型”，需要用到“实体类型（Item Type）”选项卡下的“按百分比/循环/随机”模式。

实际操作中，我推荐一套非常稳的配置套路：

1. 先把每一种产品做成一个独立的实体类型（FlowItem），统一用同一个三维模型也行，靠标签区分即可。
2. 在Source的“实体类型”页签中，选择“按标签值”或“按百分比”选项，比如设定A型70%、B型30%。
3. 给生成的实体打上类型标签（如label “Type” = 1 或 2），下游处理器按标签决定加工时间或工艺路线。

如果你的模型有几十种SKU，建议不要全部堆在Source里做，改用后面的全局表方案，那个可维护性高得多。

2.3 Source节点常用的触发选项

Source节点还有一个很重要的“触发器”页签，很多人忽略了。它其实可以在实体生成瞬间做一些定制动作，比如：

• 给新实体初始化标签；
• 设置颜色，方便可视化区分；
• 随机生成一个质量属性值，作为后续质检工序的输入。

在OnExit触发器里，我经常这样写：

/** 设置产品类型标签与初始颜色 */ treenode item = param(1); double type = duniform(1, 3); setlabel(item, "ProductType", type); if (type == 1) { color(item, 255, 0, 0); } else if (type == 2) { color(item, 0, 255, 0); }

这段代码不复杂，但能让生成出来的实物在视图中一眼看清产品类别，对调试阶段排查逻辑问题非常有用。

注意：Source生成的实体如果不设置颜色，模型里所有临时实体外观都一样，后期逻辑判断很难盯。养成“生成即打标、打标即上色”的习惯，调试效率能提高不少。

2.4 使用Source节点时容易踩的坑

踩坑一：实体类型改了，但下游处理器没有同步改。Source生成了类型2的产品，处理器却还认为只有类型1，导致加工时间永远取错。每次修改产品类型，要顺着Source下游完整检查一遍引用“类型”这个属性的位置。

踩坑二：到达间隔设成了0。当到达间隔为0，Source会瞬间产生大量实体，模型的运行速度会急剧下降，甚至出现“实体限制”或卡死现象。如果确实需要瞬时批量释放，建议用“到达数量”一次释放指定数量，而不要靠间隔0去连续生成。

踩坑三：暂停状态不清。有时候模型跑着跑着发现Source不出实体了，打开属性一看，节点状态是“暂停（Paused）”。这种情况多半是之前手动暂停过，或者某个逻辑代码里执行了stopobject()没恢复。排查时先检查节点左下角的状态标识，比盲目重设参数快得多。

3. 第二种用法：Process Flow里的Source活动

从FlexSim 7.5版本以后，Process Flow成为处理复杂逻辑的主力工具。与传统的Source节点不同，Process Flow里的Source活动有自己独立的运行机制，而且能同时生成两种东西：Token（逻辑令牌）和FlowItem（实体）。

3.1 Source活动与Source节点的核心差异

传统Source节点挂在模型树上，直接与上下游节点相连；Process Flow里的Source活动则是一个逻辑节点，强调的是“触发生成”。你可以把它理解成一个“调度中心”：可以按时间触发、按条件触发、被其他Token触发，也可以手动触发。

两者的选择，我有一条基本判断准则：

• 只是按固定节奏产生实体、让实体沿路径走一遍，用Source节点就够了，逻辑简单、不容易错。
• 如果实体要不要产生、产生后往哪去，需要依赖前序工位的完成状态、产线平衡策略、甚至Agv的调度状态，用Process Flow的Source活动更合理。

举一个典型例子：一条装配线上，只有当线尾的成品被拿走、工位上空了，线头才允许放新工件进来。这个逻辑用Source节点做，必须配一堆标签和消息；但用Process Flow的Source活动，可以在“空位释放”事件发生时，通过“触发器”激活Source，瞬间生成一个实体。逻辑直白，也方便后续维护。

3.2 Source活动的两种生成模式

Process Flow的Source活动，在属性中有两个关键选项：“将Token生成到流程中”和“将FlowItem生成到模型中”。

“将Token生成到流程中”模式，适合做纯逻辑的流程控制。比如模拟一批订单信号、模拟一个随机设备故障、模拟生产节拍。Token本身不是实体，它只是流程运行中的“指针”，跟着连线往下走，触发后续的延迟、资源占用、事件。

“将FlowItem生成到模型中”模式，则会真正在三维视图中创建一个临时实体，表现形式与Source节点产出的实体完全一致。实体生成后可以继续由Process Flow中的Sink活动回收，也可以交给下游的传统节点继续处理。

3.3 实操案例：用Source活动做拉动式生产

项目案例场景：有一台装配工位，工位前方的暂存区低于2件时，线边仓库自动补货，一次补3件。

用Source节点做这个逻辑很别扭，因为Source是“定时定量”的，不会因为暂存区数量低而自动触发。用Process Flow的Source活动，逻辑可以这样搭：

1. 建一个Process Flow，命名为“ReplenishFlow”。
2. 流程起点是Source活动，属性中勾选“将FlowItem生成到模型中”，实体类型设置为线边料箱，单次数量为3。
3. 在Source前连接一个“Wait”活动，等待“暂存区实体数变化”事件。
4. 给Wait活动设置一个条件：指定暂存区的实体数量小于2时才放行。
5. Source生成3个实体后，把它们移动到目标暂存区。

整个流程可视化程度很高，逻辑改动时也不需要去翻代码，直接在流程图上拖线就行。这就是Process Flow最大的优势——它把传统代码里的循环判断、事件监听，变成了可视化的活动节点。

3.4 Process Flow方式需要注意的细节

细节一：FlowItem生成后要与3D模型中的暂存区对接，注意坐标设置。在Source活动的“位置”选项中，可以指定生成实体的初始位置偏移量，否则实体可能生成在坐标(0,0,0)，视觉上就会“莫名其妙”出现一堆实体。

细节二：Token是可以无限产生的，而FlowItem受模型容量、暂存区容量限制。Process Flow里如果循环逻辑写得不严谨，Token会无限堆积，导致流程运行越来越卡。每次创建Token后，建议在流程结束时用Sink活动回收，避免Token残留在模型里。

细节三：调试时充分利用Token的行高亮和属性面板，观察每次触发时Token携带的变量值。Token属性的可视化调试能力，比传统Source节点强太多。遇到“为什么这里有实体而那边没有”的怪问题，先查Token流，再查实体流。

4. 第三种用法：用全局表驱动发生器做批量订单

当模型涉及的物料类型多、批量大小不固定、产品切换频繁时，把参数硬编码在Source节点里就是灾难。改一次产品顺序，得打开十几个属性面板一个个调。更好的做法是把订单数据集中到全局表里，让Source自动读取表数据来生成实体。

4.1 为什么要用全局表驱动发生器

FlexSim的全局表（Global Table）本质上是一个二维表格，可以在模型运行时被多个节点访问。把订单数据放到全局表里，相当于做了一个“虚拟订单看板”，Source只需要按行读取，就能知道这批该生成什么、生成多少、什么时候开始。

我在多个实际项目中用过这个方案，最直观的好处有三个：

1. 数据与逻辑分离。建模人员不用为了改数据重新梳理逻辑，业务人员直接在Excel里改订单就行（配合全局表导入Excel功能）。
2. 模型可配置性大幅提升。产品种类、数量、时间计划全部外置，新订单只需要加行，不需要改模型。
3. 方便做多场景实验。要试不同订单组合，直接切换全局表内容，比逐一改Source参数效率高很多。

4.2 用全局表驱动Source生成的实操步骤

下面以“订单驱动生产”为例，给出完整的可复现配置流程。

第一步：建立全局表

打开“工具”菜单 → “全局表” → 新建表，命名为OrderPlan。表结构建议如下：

第二步：Source设置

打开Source属性，找到“到达时间表”页签，选择“全局表模式”，并指定刚才建立的OrderPlan表。

这时候要注意：全局表模式的读取规则是按行执行的。每行代表一条独立的到达计划。Source会按col1的时间值触发该行，然后按col3的数量生成实体，实体之间的间隔取col4。

第三步：实体类型读取

在Source的“实体类型”页签，同样选择按全局表驱动，指定col2作为类型列。这样每一行生成出来的实体，都会自动携带对应的产品类型。

4.3 全局表方案的常见问题

问题一：全局表第一行被误读为表头。如果图方便在表里加了一行文本表头，Source会解析失败或读出0值。建模时建议明确表头行的处理方式，或者在表格第一行就放真正的数据。非要在表内写说明文字，就把Source的“跳过首行”选项打开。

问题二：时间值用数字格式而非时间格式。全局表中如果写“08:00:00”，FlexSim默认可能按字符串处理，导致解析失败。最稳妥的做法是直接用数字表示小时或分钟，比如8.0表示8点，8.5表示8点30分。

问题三：数据量超过几百行时，全局表性能依然没问题，但如果还要配合界面下拉筛选，建议把表写入“数据库表”或直接用Excel动态查询，避免每次模型启动加载过慢。

4.4 进阶扩展：用Excel外部数据驱动

如果订单表已经在Excel里维护，可以用FlexSim的“Excel导入/导出”功能，把Excel表映射到全局表。这样模型打开时自动读取最新订单，不需要手动复制粘贴。

我建议把Excel表格做成下面这种标准格式：

• Sheet名：OrderPlan
• A列：订单开始时间（数值）
• B列：产品类型（数值）
• C列：数量（整数）
• D列：间隔（数值）

然后在FlexSim里通过“文件 → 数据管理 → 导入/导出”建立Excel文件关联，后续做实验只需改Excel源文件，模型直接刷新读取。

注意：导入的Excel数据默认是覆盖式的，也就是每次模型运行时从Excel重新加载。如果模型本身还包含其他全局表数据，不要误覆盖。建议把驱动发生器的主计划表单独放一个Sheet。

5. 第四种用法：条件触发式发生器，按现场状态实时生成

前三种本质上都是“时间在驱动”，只是驱动方式不同。但实际生产里，很多情况是“事件在驱动”——比如后工位缺料了才补，设备空闲了才上料，订单确认了才开工。严格说FlexSim里没有一个叫“条件发生器”的节点，真实项目中我是组合Source + 消息机制 + 标签判断来做到的，也是标题所述“发生器”最灵活的一种用法。

5.1 条件触发的基本原理

条件触发式发生器的核心是Source的两种状态：运行（Operating）和暂停（Paused）。Source被暂停时不产生实体，被恢复后继续产生。通过灵活控制暂停/恢复时机，就实现了“按需生成”。

具体控制手段有三种：

• 下拉框操作：调试时手动暂停/恢复。
• 消息机制：其他节点或Process Flow向Source发送MESSAGE，触发其stopobject()或resumeobject()。
• 标签条件：通过全局变量或实体标签判断是否满足生成条件。

5.2 实操案例：注塑机旁缺料才补料

模拟一条注塑生产线，注塑机前有一个暂存区，低于安全库存时上游发生器才补料，一次补满20件；高于等于安全库存时不补。

步骤一：先建立一个Source节点，连接到一个暂存区Queue，再连接到注塑机Processor。

步骤二：在Source的到达间隔里写入一个“受条件控制”的逻辑。比如，在Source的“到达间隔”属性中选择“自定义代码”，写入：

/** 等待条件：暂存区容量< 安全库存时才继续生成 */ treenode queue = ownerobject(c); if (content(queue) >= 20) { return 999999; // 很长时间不生成 } else { return 0.5; // 缺料时每0.5分钟生成一个 }

这样写，Source会每0.5分钟判断一次暂存区含量——这就实现了“不够才生成”，而且不需要额外写消息恢复逻辑。

步骤三：如果想要“一次补满20个”，可以进一步把Source当成“批量发生器”，先让Source的到达数量设为1，通过OnExit触发器判断暂存区实体数，不足20就把数量补足。

更精细的做法，是配合Process Flow一起做：Process Flow里用Wait活动监听暂存区实体数变化事件，一旦低于阈值，让Source恢复运行；一旦补足，让Source暂停。这个方案的响应速度比轮询判断快得多，适合高频、高精度的仿真场景。

5.3 结合标签做多条件判断

条件触发式发生器并不只能看数量，还可以看质量、看批次、看状态。

举个例子：当“订单确认”标签等于1，并且“设备空闲”标签等于1，并且“当前时间处于班次内”，Source才开闸放行。这种多重条件的判断，用Source属性页里的“可用性”功能实现最顺手。

具体操作方式是：在Source的“可用性”中设置按“MTBF（平均故障间隔）/MTTR（平均修复时间）”运行，但把故障触发条件改成自定义条件代码。代码如下：

/** 只有当orderRelease == 1 且 machineIdle == 1 时才运行 */ int orderRelease = getlabel(model(), "orderRelease"); int machineIdle = getlabel(model(), "machineIdle"); if (orderRelease == 1 && machineIdle == 1) { return GLOBAL_RUNNING; } else { return GLOBAL_FINISHED; // 相当于暂停 }

用这种方式，Source就像一个有“闸门”的执行器，完全跟随现场状态动作。这种建模方式尤其适合做推拉结合的生产系统：正常情况下按节拍推式生产，异常情况或紧急插单时，通过条件触发紧急释放。

5.4 条件触发方案的避坑经验

经验一：不要过度轮询。在到达间隔里写条件判断，虽然实现简单，但如果延迟时间设得太短（比如0.01秒），会消耗大量CPU资源。建议轮询间隔不要小于0.1秒，否则大型模型中会明显卡顿。

经验二：消息恢复Source时，注意消息的接收对象。如果在Process Flow中用“Send Message”活动给Source发消息，接收对象必须填Source节点路径，否则消息发空，Source永远不会恢复。

经验三：标签命名要统一规范。条件触发式发生器往往要读取多个标签，如果模型里一会叫orderRelease、一会叫order_release，排查时会相当痛苦。建议从建模第一天起就维护一个“标签命名规范表”，所有标签统一名词风格、统一大小写。

6. 常见问题与排查技巧实录

每次线下培训或项目支持，被问得最多的问题都集中在“发生器不给实体”“实体数量不对”“模型卡顿”这三类。这里把排查思路整理成速查表，遇到问题可以直接对号入座。

6.1 发生器不发实体，怎么排查

6.2 实体限制与模型卡顿

“FlexSim实体限制怎么办”这个话题，在软件社区里热度一直很高。所谓实体限制，通常不是FlexSim的许可证限制，而是模型运行中出现的大量实体堆积导致的内存与运存问题。

出现实体堆积的常见原因：

1. 下游处理器加工时间远大于上游发生器的生成间隔。造成实体在下游不断排队。
2. 循环逻辑中创建了无限数量的Token或实体，且没有有效回收。
3. 暂存区的容量上限设成了超大值，实体全堆起来。
4. 实体生成后没有进入后续处理流程，变成了“孤儿实体”，永远停留在动态实体列表中。

排查方法：运行模型时，打开“工具 → 调试 → 性能报告”，查看实体总数和内存变化。如果实体总数持续线性增长，多半是逻辑中有资源泄漏。

针对实体限制的优化建议：

• 将发生器的生成模式从“到达间隔”改为“到达时间表”，明确每个时刻只生成必要实体。
• 给下游暂存区设置合理容量，模拟现实中的缓冲限值。
• 在Process Flow中坚决使用Sink活动回收无用实体或Token。
• 优先使用“按订单/按节拍”生成，而不是一直开着“无限生成”。

6.3 批量数量不对的排查清单

批量数量不对通常是三种原因：

原因一：到达时间表中，同一条记录被重复触发。检查时间轴，确认每条记录的时间是否唯一，是否存在重叠。

原因二：全局表中的“间隔”列没有设置，导致一次到达后连续把整列数据当成数量。常见于列含义理解错位，要检查每一列的表头含义是否正确映射。

原因三：在OnExit触发器里又追加了生成逻辑。有些二次开发场景中，触发器和到达数量叠加，导致实体数翻倍。排查时把触发器临时禁用，看数量是否恢复，就能快速锁定问题。

6.4 实体“跑飞”或位置错乱

实体生成后没有出现在预期位置，一般与Source的“位置/方向”设置有关。可以检查以下三项：

• Source的“发送到连接端口”是否正确；
• 实体生成时是否设置了固定坐标或沿网络节点路径；
• 如果使用Process Flow生成FlowItem，Source活动的坐标偏移是否设置正确。

如果实体跑飞到了(0,0,0)，最直接的修复方法：在实体生成的OnExit事件里统一设置一个初始位置：

treenode item = param(1); treenode source = param(2); setloc(item, xloc(source), yloc(source), zloc(source) + 0.5);

这段代码能保证实体永远出现在Source附近，而不是跑到了世界坐标系原点。

7. 实操心得：做一个能真正落地的发生器方案

牌面上的四种用法，模型里真正需要结合使用。以一个我实际做过的仓储拣选模型为例。仓库有100个SKU，订单从Excel导入，每个订单包含多行商品明细，拣选线分4条。

这个模型的“发生器”最终是这样设计的：

• 订单入口：用Process Flow的Source活动生成Token，每个Token代表一个订单。
• 订单明细读取：Token创建后，读取全局表中对应的订单明细行，逐行创建“拣选任务实体”。
• 实体生成：用全局表驱动的传统Source方式，负责生成不同类型的货品实体。
• 库存不足联动：拣选任务中，一旦某SKU库存低于安全线，触发条件式发生器，生成补货任务。

这里同时用到了第二种（Process Flow）、第三种（全局表）、第四种（条件触发）三种发生器用法，第一种Source节点负责最底层的货品生成。四种方式各管一段，逻辑清晰且互不干扰。

我做仿真项目有一个习惯：先把生成策略写成一个表格，列清楚“谁生成、什么时候生成、生成多少、受谁控制”，然后再去模型里画流程图。这样能避免代码写一半发现逻辑方向错了，返工成本能低很多。

另外推荐大家多看看FlexSim自带的示例模型。安装目录下有几十个官方demo，从单一Source到复杂PF逻辑都有。学的时候不要光看三维画面，要重点看两样东西：一是Source和各活动节点的属性设置，二是Process Flow里Token的走向。

8. 写在最后的小技巧

用发生器这么多年，我最大的体会是——别把Source当成一个只会“吐东西”的节点。它本质上是一个可控制的事件源，只要控制逻辑足够丰富，它可以是订单入口、补货信号、设备故障、甚至客户需求模拟器。把它当“对象生成器”理解，模型能玩的花样就多了很多。

最后分享一个我自己经常用的调试技巧：在Source的OnExit触发器中加一行output("Generated " + getlabel(item, "type"));，把每个生成实体的类型输出到控制台。排查“为什么这个类型跑到那里去了”这类玄学问题时，一行日志往往比盯半天可视化界面有效得多。

这篇文章覆盖到的四种发生器用法，基本可以应对日常仿真项目里90%以上的生成逻辑需求。后续如果你在项目中遇到更特殊的生成场景，欢迎带着具体案例来讨论——仿真建模这东西，讨论着讨论着，思路就通了。