企业官网建设流程全解析

简介：《TrueTime 2.0 使用说明》面向在 MATLAB 环境中开展网络化运动控制、资源调度仿真与教学的读者，聚焦 TrueTime 2.0 工具箱从获取、安装到配置、验证及模块使用的完整入门路径。文档围绕工具箱放置、路径添加、系统环境变量设置、启动脚本调整、GCC 编译器安装与 mex 配置、make_truetime 成功验证等关键环节展开，并对 Kernel、Simulator、Controller 等模块及仿真实验环境作说明，便于读者理解最大误差优先调度、优先级反馈控制等场景下的建模与调试思路。资源包共 1 个 docx 文件，约 402KB，轻量便于查阅。已有 1593 人学习，适合 MATLAB 初学者、运动控制课程学生及需要快速搭建 TrueTime 仿真环境的工程技术人员对照排错与查漏补缺。

1. TrueTime 2.0 是一套要自己编译的网络化控制仿真内核，并非“装完就能用”的插件

在 MATLAB 里做运动控制仿真，绕不开两件事：任务什么时候被调度、消息在网络上要走多久。TrueTime 2.0 就是把这两件事变成可观测对象的 Simulink 工具箱——Kernel 模块跑你写的调度代码，Network 模块模拟时延、丢包和带宽占用，让“最大误差优先调度”“优先级反馈控制”这类策略在真实控制器落地之前先被压测一轮。这份 truetime2.0使用说明.docx 记录的正是：怎么把 truetime 从一堆 .m 与 .c 文件，折腾成 MATLAB 里点得开的模块库。适合做资源调度、实时任务仿真、控制回路时延分析的从业者；只想画一条阶跃响应的，Control System Toolbox 就够了。

2. 解压包里有什么：从 kernel 到 examples 的目录分工

2.1 先看清目录职能，别急着往 toolbox 里塞

拿到 truetime-2.0 的压缩包，多数人的第一反应是双击解压、拖进 toolbox、重启 MATLAB，然后发现命令窗口里输入truetime依然是红的。问题不在装，而在没看清包里谁是源码、谁是二进制、谁是编译脚本。

解压后一般能看到kernel目录，这是整个工具箱的心脏：里面有 C 源码（各种*.c、*.h）、已经编译好的 MEX 二进制（*.mexw32/*.mexw64）、负责初始化的init_truetime.m、负责把源码重新编译成 MEX 的make_truetime.m，以及给 Simulink 用的模块封装文件。除了 kernel，还有examples一类的示例目录，里面是现成的.mdl模型，拿来对照模块连接关系非常省时间。

所以判断“这份包能不能用”，看的不是压缩包大小，而是三件事：MEX 二进制有没有对应你系统的位数、make_truetime.m在不在、kernel下的源码是否齐全。位数这点很容易翻车——64 位 MATLAB 加载 32 位 MEX 会直接报无效 MEX 文件，报错信息还相当含糊，看起来像路径没加对，实际是二进制不匹配。

原说明里提到“set path 里共包含 4 个关于 truetime-2.0 的文件，最好都包含进去”，这句话的背景就是路径对话框里 kernel 相关条目不止一条。稳妥做法是整目录递归加入，而不是手工挑几个.m。手工挑的后果是：编译能过，仿真一跑就提示某个内部函数 undefined，排查起来非常耗神。

2.2 装到 toolbox 还是独立目录：一次选择决定后面几年

安装位置有两个流派，我两种都长期用过，差别比想象中大。

我现在的默认选择是第二种，理由很实际：做网络化控制仿真的人，机器上大概率同时存在两三个 MATLAB 版本，一份 toolbox 里塞一套 truetime，切版本就得重装，改一次源码还要同步到每一份拷贝。独立目录加启动脚本，改一次全生效。

如果一定要走第一种，注意复制前先确认目标toolbox目录是不是受系统保护。Windows 下往Program Files里写文件，不做管理员提权是写不进去的，复制动作看似完成了，实际只复制了一半文件，后面编译时才会以“找不到某个头文件”的形式暴露。

2.3 setpath 的正确写法：getenv、genpath、savepath

图形界面点 Set Path 当然可以，但那种操作不可复现，换台机器就得再来一遍，而且很难跟同事说清到底加了哪几层。我习惯写成脚本：

% 把 truetime 挂进搜索路径，并写进 pathdef.m 固化 root = 'D:\MATLAB_toolbox\truetime-2.0'; % 换成你自己的解压位置，路径里不要有空格和中文 assert(exist(root,'dir')==7, '目录不存在，先检查解压路径'); % genpath 递归收集子目录，避免只加一层漏掉私有目录 addpath(genpath(fullfile(root,'kernel'))); addpath(genpath(fullfile(root,'examples'))); % 示例可选，调试期建议加上 rehash toolboxcache; % 刷新路径缓存，避免"刚加完仍找不到" savepath; % 写回 pathdef.m，下次启动自动生效

这段代码的关键在三个地方。genpath是递归收集，kernel下面如果还有子目录（放私有函数或编译中间产物的那种），只写addpath(fullfile(root,'kernel'))是漏的，而这类遗漏往往表现为“函数都在，但一调用就报内部错误”。rehash toolboxcache解决的是缓存滞后，刚 addpath 完立刻which查不到的情况时有发生，加这一句省一次重启。savepath是固化，把当前路径写进pathdef.m；如果这一步报“无法写入”，说明 MATLAB 安装目录没有写权限，需要以管理员身份启动，或者退回到启动脚本方案。

验证是否真的挂上了，不要靠肉眼看路径列表，用命令确认：

which ttkernel -all % 应该只返回一份结果，返回多份说明路径重复 exist('init_truetime','file')% 返回 2 表示找到 .m 文件

which -all返回多份是很典型的信号：说明工具箱在多个位置各有一份，MATLAB 用的是哪一份不由你决定，而由路径顺序决定。这种重复加载在编译期没感觉，运行时会出现“改了源码却没生效”的玄学现象。

3. 环境变量、startup.m 与 init_truetime.m：让工具箱开机就在

3.1 环境变量解决的是“编译器找不到”，不是“工具箱找不到”

原说明里让你在系统变量里新建环境变量，这一步经常被误解成“给 truetime 配置路径”。实际不是。addpath管的是 MATLAB 内部能不能which到函数；环境变量PATH管的是 MATLAB 启动的外部进程（尤其是mex调起的编译器）能不能找到gcc.exe。

两套查找机制互不相干，所以会出现这种局面：which make_truetime好得很，一执行就报“未找到支持的编译器或 SDK”。这时去翻路径列表是白费劲，该看的是PATH。

我的做法是把编译器目录挂进系统PATH，而不是只挂进当前会话：

:: 以管理员身份打开命令提示符，把 64 位 GCC 的 bin 目录追加进系统 PATH :: /M 表示写系统变量；不加 /M 只影响当前用户，换账户登录就失效 setx PATH "%PATH%;C:\gcc64\bin" /M

执行完必须重开命令提示符和 MATLAB，setx写的是注册表，已经运行的进程读不到新值。这一点被忽略的概率极高，表现为“明明配了环境变量，MATLAB 里还是找不到编译器”。

挂好之后在 MATLAB 里直接验证，别猜：

[st, out] = system('where gcc'); disp(out); % 能打印出 gcc.exe 的完整路径才算成功

如果这里返回空，问题一定在系统PATH，与 truetime 本身无关。另外提醒一句，如果你机器上同时装了 Visual Studio 一类的编译器，mex -setup列表里会出现多个候选，选哪个不是随便挑的——要和make_truetime.m里写的编译选项匹配，否则编译阶段能过，链接阶段会以一堆 undefined reference 收场。

3.2 startup.m 加 init_truetime.m：一套能复现的启动组合

init_truetime.m这个文件的作用是初始化内核相关的全局状态，比如注册模块回调、设置默认参数。它本身不会自动执行，得有人调。

原说明里的做法是把init_truetime.m复制到 MATLAB 安装目录下toolbox\local文件夹。这一步是有道理的：local目录在搜索路径上且优先级很高，放进去以后任何工作目录下的脚本都能直接调到它，不用额外 addpath。缺点是升级 MATLAB 时这个文件会被覆盖或丢失，属于“能用但不好维护”的方案。

我更倾向的组合是在startup.m里一次性把路径和初始化都做掉：

% startup.m —— 放在 MATLAB 默认的 userpath 目录下，每次启动自动执行 root = 'D:\MATLAB_toolbox\truetime-2.0'; if exist(root,'dir') addpath(genpath(fullfile(root,'kernel'))); % 初始化内核：只在函数可调用时执行，避免工具箱缺失导致启动报错 if exist('init_truetime','file') try init_truetime; catch ME warning('truetime 初始化失败: %s', ME.message); end end end

这段有几个细节值得说。用exist(root,'dir')做前置判断，是为了让这份startup.m在没装 truetime 的机器上也能安全执行——很多人把配置写死在启动脚本里，换台机器一开 MATLAB 就是一片红字。try/catch包一层是因为init_truetime内部可能依赖特定目录结构，路径不完整时会抛错，而这个错不该阻断整个 MATLAB 启动。warning而非error也是同理：启动脚本失败了要能看见，但不能把人挡在门外。

startup.m放哪里？执行userpath看返回值，那个目录就是 MATLAB 每次启动会去找startup.m的地方。放到别处不会被执行，这也是“我明明写了 startup.m 却没生效”的最常见原因。

3.3 matlabrc.m 那条“另存为 matlab.mat”，我劝你别照抄

原说明的步骤 4 是：打开toolbox\local\matlabrc.m，不做任何修改，直接 save，把文件名改成matlab.mat保存到同一位置。

这一步在机制上是无效的。matlabrc.m之所以特殊，是因为 MATLAB 启动时会自动执行这个.m脚本；把它另存成.mat之后，它就变成了一个二进制数据文件，启动时不会被执行，也不会被加载。换句话说，这个动作既不改变启动行为，也不产生任何配置效果。

真正想做的是在启动时执行初始化，那么两条路：一是前面说的startup.m，二是直接在matlabrc.m末尾追加addpath与init_truetime调用。后者能用，但我不推荐——matlabrc.m属于 MATLAB 安装文件，升级或修复安装时会被覆盖，你加的几行会静默消失，然后在某次重装后突然发现工具箱又不见了，这种“后悔药没处买”的场景我经历过一次。

如果你已经在matlabrc.m里改过东西，验证方法很简单：重启 MATLAB 后执行which init_truetime，能返回路径就说明生效了。返回空则说明改动没落地，或者被startup.m里的其他rmpath干掉了。路径操作最怕的就是这种互相覆盖，所以我一般会在启动脚本末尾加一句打印，把当前 truetime 的实际路径打出来，出问题时一眼就能看到。

4. 编译器与 make_truetime：不跑出 successful 就等于没装

4.1 为什么内核要用 C 编译，而不是纯 .m

TrueTime 的 Kernel 模块要做的事情，是在 Simulink 的每个仿真步长里推进一个“虚拟操作系统”：维护任务队列、比较优先级、处理中断、推进仿真时钟。这些操作每步都要执行，一个几秒钟的仿真跑下来可能是几十万次调用。纯 MATLAB 解释执行的.m代码在这个量级上会成为瓶颈，所以内核主体用 C 写成，通过 MEX 接口挂进 MATLAB。

理解了这一层，很多事情就顺了：为什么解压包里既有.c也有.mexw64——前者是源码，后者是编译产物；为什么换了 MATLAB 版本或换了机器架构（32 位升 64 位）要重新编译——MEX 二进制与 MATLAB 的 ABI 绑定，不通用；为什么make_truetime失败时必须停下来修——没有 MEX，Kernel 模块就是个空壳，你在 Simulink 里拖得出来，一仿真就报错。

也正因为是编译产物，它对本机环境比纯.m工具箱敏感得多。纯.m的工具箱，扔进路径基本就能跑；带 MEX 的工具箱，编译器、位数、运行时库任意一环不匹配，都会在运行期炸出来。

4.2 mex -setup 与 64 位 GCC 的匹配

编译器选择这块，原说明里给的经验是“网上找的编译器一直不成功，最后用了某个 64 位的 GCC 发行版”。这个结论方向是对的：MATLAB 对编译器的支持是有白名单的，版本跨度过大会直接拒绝。

mex -setup的交互过程本身不复杂，但要注意两点。第一，选完 C 编译器之后，如果工具箱里有 C++ 源文件，还要再跑一次mex -setup C++，两个是分开配置的。第二，配置结果不是永久的，换 MATLAB 版本、换用户账户、甚至某些情况下清理临时目录都会重置，所以这一步要写进你的安装记录里，别指望一次配好管三年。

配置完成后先做一次最小验证，不要直接上make_truetime：

% 先编译一个 Hello World 级别的 MEX，确认工具链本身是通的 mex -v mytest.c

-v是 verbose，会把调用的编译器路径、命令行参数、链接的库全部打出来。工具链有问题时，这一屏输出就是黑匣子记录仪：能看到它到底调的是哪个gcc.exe、带没带-m64、链接阶段找了哪些目录。这一步过了，再去编 truetime 才有意义，否则你分不清是工具链坏了还是源码有问题。

顺便说一个很常见的现场：机器上装了多个 GCC，PATH里排前面的是 32 位版本。mex -setup看起来成功了，编译也能产出东西，但产物是 32 位 MEX，在 64 位 MATLAB 里加载时报“无效的 MEX 文件”。解法是把 64 位那个目录在PATH里前置，或者干脆只保留一个。

4.3 make_truetime 的输出解读与二次编译

make_truetime是工具箱自带的编译驱动脚本，做的事情是遍历 kernel 目录下的源文件、逐个调mex、把产物放到指定位置。原说明里写“如果出现警告，先不用管，最后出现 successful 表示配置成功”，这个判断标准基本准确，但值得展开。

编译过程中出现 warning 是常态，多数是类型转换、未使用变量、旧式函数声明这类，不影响功能。真正要盯的是两类信息：一是error关键字，出现即失败，必须解决；二是最后那行汇总，只有明确打出成功标识才算过。夹在中间的“某某文件 skipped”也要留意——跳过有时是因为已经有对应 MEX 产物，有时是因为源文件缺失，两种情况的后果完全不同。

如果编译中途失败，修完问题不要直接重跑。先清理已有产物：

% 清理旧的 MEX 产物，避免新旧混用导致的诡异行为 root = 'D:\MATLAB_toolbox\truetime-2.0\kernel'; old = dir(fullfile(root,'*.mex*')); for k = 1:numel(old) delete(fullfile(root, old(k).name)); end disp(['已清理 ', num2str(numel(old)), ' 个旧 MEX 文件']);

之所以要清，是因为部分编译失败会留下半成品 MEX 文件。下次编译时脚本检测到产物存在就跳过，于是你拿到的是一个残缺的二进制，加载时报的错跟源码毫无关系。这种“编译成功但跑不起来”的玄学问题，十有八九是旧产物在作祟。

4.4 三条验证命令

编译完成后别急着建模型，先用命令确认三件事：函数找得到、MEX 加载得了、模块库出得来。

which ttkernel -all % 1) 确认内核主函数只解析到一份 exist('ttkernel','file') % 2) 返回 3 表示是 MEX 文件，返回 2 是 .m，都不是就有问题 truetime % 3) 应该弹出模块库浏览器窗口

第二条的返回值含义要记牢：3是 MEX，2是普通.m。如果你期望加载的是编译好的 MEX，却返回了2，说明路径里存在同名的.m文件且排在前面，编译器编出来的东西根本没被用到。这种情况在同时保留了源码目录和产物目录时特别容易发生。

第三条执行后弹出模块库窗口，是整条链路通的最终标志。弹不出来但也不报错的，通常是被其他窗口挡住了，或者模块库的slblocks注册没生效，检查which slblocks是否指向 truetime 那一份。

5. 避坑与排查：五个我实际踩过的坑

5.1 输入 truetime 提示 Undefined function

现象：编译全过，make_truetime也打出了成功标识，但命令窗口输入truetime提示函数未定义。

原因：模块库入口函数的搜索路径没有被正确加载。make_truetime编译的是内核，模块库入口是另一套.m和封装文件，两者不在同一层目录。原说明里“只包含到 kernel 的文件夹，如果出错，再重新包含进去”这句话，对应的正是这种情况。

解决：把 kernel 下的子目录用genpath递归挂进去，而不是只addpath一层。挂完执行rehash toolboxcache再试。仍然不行就用which truetime -all看它到底解析到了哪里，返回空说明确实没挂上。

5.2 make_truetime 报找不到编译器

现象：脚本跑到第一个源文件就中断，提示未找到受支持的编译器或 SDK。

原因：mex -setup配置的编译器与实际PATH里的不一致，或者setx之后没有重开 MATLAB，进程读到的还是旧环境。

解决：先在 MATLAB 里system('where gcc')确认能定位到编译器，再跑mex -setup重新选一次。两条都通过之后才重跑make_truetime。顺序不能反，否则你会一直在错误的方向上试。

5.3 仿真一跑就报 MEX 无效或版本不匹配

现象：模型能搭、参数能设，一点开始仿真立刻报无效 MEX 文件。

原因：产物位数与 MATLAB 位数不符，或者用了别的 MATLAB 版本留下的产物。32 位与 64 位混用是最常见的版本错配。

解决：按 4.3 的脚本清掉所有*.mex*，用当前 MATLAB 重新编译一遍。如果重新编译后依旧报同样的错，检查是不是有多份 truetime 在不同路径下，which ttkernel -all返回多份就要手动清理重复目录。

5.4 每次重启 MATLAB 路径就丢了

现象：当天配好能用，第二天开机又提示函数未定义。

原因：只做了会话内的addpath，没做savepath，也没有写启动脚本。

解决：二选一。要么在 addpath 之后savepath固化到pathdef.m；要么写startup.m放在userpath目录下。两条都做也不冲突，但要注意顺序，启动脚本里的rmpath会覆盖pathdef.m的效果，排查时优先看启动脚本。

5.5 路径里有空格或中文，编译随机中断

现象：编译到某个文件突然报错，重跑一次可能又过了，位置还不固定。

原因：路径中的空格和中文在某些编译中间步骤里没有被正确转义，导致命令行被截断。

解决：把工具箱挪到纯英文、无空格的短路径下，比如D:\MATLAB_toolbox\truetime-2.0。这条几乎没有例外，凡是带 C 编译环节的工具箱，路径洁癖都是值得的。

6. 让模块库真正跑起来：一个最小内核脚本与参数对照

装完只是拿到工具，能不能用要看内核脚本写对没有。TrueTime 的 Kernel 模块挂的是一个.m文件，里面用一套tt*前缀的函数描述任务和调度策略。下面这段是我常用的最小骨架，两个任务加一个网络句柄，够验证整条链路：

function ttkernel_minimal % 固定优先级调度，两个周期任务，一个网络事件处理 ttInitKernel('prioFP'); % 调度策略：固定优先级 % 周期任务：偏移 0，周期 10 ms ttCreatePeriodicTask('ctrl_task', 0, 0.010, 'ctrl_code'); % 网络句柄：消息到达时触发，优先级数值越大越低 ttCreateHandler('net_handler', 2, 'net_code'); ttAttachNetworkHandler('net_handler'); end

ttInitKernel的参数决定调度器类型，'prioFP'是固定优先级，语义直观、结果可预期，适合先跑通再换策略。ttCreatePeriodicTask的四个参数分别是任务名、首次触发偏移、周期和回调函数名，周期单位是秒，写0.010就是 10 ms，别写成 10。ttCreateHandler建的是事件句柄，网络消息到达属于事件而非周期，必须挂句柄，否则消息进来了也没人处理。ttAttachNetworkHandler的签名在不同小版本间有差异，以你解压包kernel目录下同名文件的函数声明为准，不要照抄网上的老例子。

参数怎么调，我一般按这张表起步，再按仿真结果收敛：

这张表没什么神秘，核心就一句：先让仿真跑出稳定可复现的结果，再去谈策略优劣。步长不收敛的情况下比较调度算法，结论是没有意义的。

现在我每次在新机器上装完，都会强制走一遍“编译 → 三条验证命令 → 跑一遍最小内核”的流程，哪怕时间再紧也不跳。因为跳过之后省下的十分钟，往往会在某次答辩前一小时以“模块库打不开”的形式还回来。这份说明文档的价值也在这里：它把散落在各个论坛里的步骤串成了一条能照着走的线，虽然个别步骤（比如那个另存为mat.mat的操作）值得商榷，但主线是对的。希望帮到你。

本文还有配套的精品资源，点击获取