24．在node interfaces里面设置属性为set,promoted和hidden有什么意义？ hidden可以在仿真的时候看不到设置的这个参数，promoted可以在仿真的过程中根据需要改变参数的值
25．我在学习opnet的tutorial的packet switching1 时最后仿真出现下面的错误，请问如何解决?
Creating library PS_pksw_net-scenario1.i0.nt.lib and object
PS_pksw_net-io1.i0.nt.exp dpt_propdel.i0.ps.o : error LNK2001: unresolved external symbol _link_de PS_pksw_net-scenario1.i0.nt.so : fatal error LNK1120: 1 unresolved exter
在运行仿真时，选择declare external file，将link_delay.h文件包含即可。 26．请问opnet里如何提取统计信息作为反馈控制变量？例如将丢失率提取出来后，通过函数将其反馈回模型中进行控制。 可以试试stat_intrpt函数。
27．模型中的数据线中的src stream [n]和dest stream [n]中括号中的序号n分别表示什么意思？
op_pk_get(STRM NUM)的参数，会根据n来选择数据线的。
28．pipeline stage 的函数是怎么调用的啊？为什么我的数据在被接收端的时候那几个pipeline 函数并没有执行完呢？只执行了3个函数，后面就没有了，结果数据不知道扔哪去了，上层也没有stream中断是怎么回事呢？
pipeline state 函数体接口是规定的，由KP调用。在stage 2 有连通性的检查，如果false ，则以后的stage 都不需执行了。
29．仔细察看了一下程序，FIN和FOUT都是配对的。在一个Idle的状态中，什么操作也没做。但是程序执行了好长时间之后，突然告诉说Abnormal function stack function。就是在Idle状态出的错。可是哪个状态根本就是空操作。而在.pr.c文件中，发现所有的process的.pr.c文件中的那个最全的函数都是只有FIN，没有FOUT的。请问出现上述错误还有可能是何原因？
查看事件列表，有可能是事件列表满的缘故，你可以试着改变preference里面的一个event_speed_parameter参数出现该问题的设置不同，出现的时间也会不同。
30．请问OPNET的背景路由流量的如何配置？ 三种方法：
application configi. conersation pair
link load
31．怎样在mac层获取在pipeline stage中计算的某些参数的数值，如接收功率的数值？
可以用pwr = op_td_get_dbl (pkptr, OPC_TDA_RA_RCVD_POWER)。 32．我对某个pipeline 函数做了一点修改然后以另外一个名字另存了一下，但是在模块中却不能把原来的pipeline函数改成重新命名的
pipeline函数这是怎么回事啊？你修改后的文件名要与函数名相同，然后得用OPNET自带的EXTERNAL INTERFACE提供的工具编译就可以了。OPNET与VC调试经验总结基于Debugging in OPNET withMicrosoft Visual C++ 调试的文档（资料下载区提供)，有一些经验总结如下：
（1）修改Preference中的环境变量时，/Od与/Zi之间要有空格，另外注意O不是0。
（2）除了修改bind_shobj_flags、comp_flags、comp_flags_cpp外，还要修改bind_static_flags：即后面添加/DEBUG。可以从文档中的示意图中看出。记着，中间一定要有空格。
（3）如出现上述设置上的问题，可以从编译结果中查看问题。（建议可以故意在一个process model中加一条语法错误的语句，然后编译看列出的出错信息。） （4）在attach process时，如果看不到任何process，尽量关闭不必要的程序，只留下opnet的project窗口和VC。如果还不行，就要给VC打SP5补丁了。不过有一种更简单的方法，就是在任务管理器中，在进程中找到op_runsim_de v.exe进程，右键，然后调试，即可和VC进行联调。 （5）修改Simulation model的environment files时，一般不需将Force Compile设为enable，因为调试时一般process model都已编译好。如果把Force Compile设为enable的话，每次启动simulation都会把项目中包含的所有的process model重新编译，会耗很长时间。但是为了保证代码为最新改写过得，建议还是enable为好。
（6）如果不想让debug窗口自动关闭，可以把consle_exit_pause改为TRUE，仿真完后会提示Press
（7）编译的时候产生调试信息的参数是 /Z7 或 /Zi，(注意：/Z8并不是合法的参数)。
调试时还需要关闭编译器的优化功能，所以还要加上/Od。连接的时候需要保留调试信息，所以在bind_shobj_flags后面要加 /DEBUG。
（8） config simulation里面的debug，目的是让op_runsim运行在debug模式下，等效于console下面的 -debug。force_compile的作用是每次编译时都重建所有的模块，以使你在VC下面看到的源程序都是最新的。
（9）在VC调试时，从断点后开始单步运行，最后总会走到一个向汇编中的机器代码的地方。odb那边也不能敲任何命令。这很正常，那个汇编的地方就是OPNET的内核之类的东西。不用管它，在VC里面再选run就行了。程序会运行到VC的下一个断点，或者ODB重新可以敲命令了。 （10）最基本的一个问题，在OPNET调试时，报错：
bind_so_msvc: Unable to execute bind program (Win32 error code: 2) Check that Visual C++ has been installed correctly, and that its BIN directory is included in the Path environment variable.
那么可以按照一般的方法来手动添加环境变量，但是就笔者经验，即使当时通过，之后可能还会出现问题。最彻底的办法就是VC和OPNET重装一遍，先安装VC，安装时，要选择注册环境变量。OPNET也不能偷懒，就一步一步按顺序安装吧。
这些都是笔者和一些使用OPNET的朋友的一些总结，有什么不足还望大家赐教，互相交流，共同进步！ OPNET信道模型概述
在OPNET模型中，当包被传送到发送器请求发送后，实际中的情况是包将立即被发送到通信信道上进行传输，因此OPNET必须对通信信道进行建模，也就是在模型中要实现物理层的特征，以便将信道对包产生的传输效果考虑进整个网络模型。OPNET将信道对包产生的传输效果建模为若干个计算阶段（称为pinpeline stage），最终来判断该包能否被接收到。
Pipeline的典型参数是一个packet指针，也就是说，pipeline是针对每个包来计算它在物理信道上的传输效果的。为了承载
pipiline所需或计算的信道参数，每个包都包含着由transmission data attribute(TDA)的一组值构成的存储区，当包的传输效果计算进入某一pipeline stage时，系统内核为TDA分配初始值或者根据计算结果来设置TDA值 。这一组TDA值可以为后续的pipeline stage提供计算的依据。
OPNET将传输信道划分为三种：点对点链路（point to point Link），总线式链路（bus Link）和无线链路（radio Link）
。每一种链路由若干个标准的，缺省的pipeline stage组成。用户可以对缺省的pipeline stage 进行修改以适应用户所需的信道类型：用户可以在pipeline里定
义自己的TDA，还可以调用系统内核里的支持对TDA进行操作的内核过程（KP）来编程实现自己的信道模型。
OPNET中缺省的pipeline stage模型文件后缀名为.ps.c，经编译后形成的目标文件后缀名为.ps.o。所有的三种信道的缺省
pipeline stage 文件都存储在
1） 传输时延阶段：模型文件dpt_txdel.ps.c。传输时延描述的是第一个比特发送时间到最后一个比特发送时间之间的时间间隔。
计算方法：从包里读取传输该包的信道的标志号（ID）； 有了信道ID后，即可读取信道的数据速率； 读取包的长度；传输时延=包长/数据速率； 把计算而得的传输时延值写到包的TDA里。
2） 传播时延阶段：模型文件dpt_propdel.ps.c。传播时延描述的是第一个比特开始发送时间到第一个比特到达时间之间的时间间隔 。计算方法： 从包里读取传输该包的链路标志号（ID）；有了链路ID，即可读取链路的\属性值； 把该传播时延值写进包的TDA中；
3） 误码数目分配阶段：模型文件dpt_error.ps.c。
计算方法：读取链路的标志号（ID）；读取链路的误码率\属性值，即单个比特可能误码的概率；读取包长；计算\正好发生k个比特误码\的概率P（k），那么可以得到\至多发生k个比特误码\的概率P=P（0）+P（1）+……+P（k）；产生一个在{0，1}内平均分布的随机数r；如果随机数r小于等于\至多发生k个比特误码\的概率P，那么就\认定\就是这个包在信道上传输的误码数目；如果r大于P，那么就将k的值加1，反复计算以得到算法能够接受的误码数目；将误码数目写进包的TDA里。
4） 纠错阶段：模型文件dpt_ecc.ps.c。
计算方法：读取接收器的标志号（ID）；读取接收器能纠正的误码数目门限值\thr
eshold\属性值；读取前面计算的错误数目；将错误数目与纠错门限
\ threshold\比较，判决该包是否能被正确接收；将判断结果写进包的TDA里。总线链路的pipeline模型由六个缺省的pipeline stage组成，其中第一个阶段针对每个传输只计算一次，而后面的五个阶段针对各个可能接收到这次传输的接收器分别计算一次。
具体描述如下：
1） 传输时延阶段：模型文件dbu_txdel.ps.c。 计算方法：与点对点链路情况一致。
2） 封闭性计算阶段：模型文件dbu_closure.ps.c。
这个阶段的意义在于判断各个接收器节点是否能够接收到这次传输，即链路的封闭性。针对每个接收器都有一个判断结果。有了这个结果以后系统内核就可以决定是否再为该接收器执行后面的计算进程。这个判断的好处是提高了仿真效率，因为若已知某接收器不能接收到这次传输，就不必为其计算传播时延，冲突等值，避免了进行不必要的计算。计算方法：缺省认为所有bus上的站点都能接收到这次传输，因此直接把判断值写进包的 TDA里。 3） 传播时延阶段：模型文件dbu_propdel.ps.c。
计算方法：读取链路的标志号（ID）；读取链路的单位距离的传播时延\属性值。注意在这里的delay属性与点对点链路的delay属性意义不一样。这里指的是单位距离的传播时延，而点对点链路中的delay直接指的是总传播时 延。因为点对点只涉及到单条链路的传播时延，而总线链路要针对不同接收器即不同的传播距离计算出多个传播时延；读取收发器之间的距离间隔；二者乘积值即为传播时延，将其写进包的TDA里。
4） 冲突检测阶段：模型文件dbu_coll.ps.c。
在某个包的整个接收时间内（第一个比特到达时间到最后一个比特到达时间之间的时间间隔），可能会发生多次传输事件，于是对于该包来说，可能要遭遇多次冲突事件。在OPNET中，每当发生一次冲突事件，就调用本pipeline stage一次，以记录这次冲突事件。
这个pipeline stage对每个包传输不是总要调用，它只是在发生冲突时调用，而是否发生冲突是由系统内核来判别的。这个计算进程区别于其他的pipeline stage，有两个包指针参数：第一个是先到的分组，第二个是后到的分组（就是触发冲突事件的那一个）。
计算方法：如果前一个包刚好在后一个包开始传输时结束了接收，则不考虑为一次冲突。因此读取前一个包的结束时间，将其与当前仿真时间进行比较。如果相等或小于则不认为冲突。如果大于，则将前后两个包的记录冲突次数TDA都加一。
5） 误码数目分配阶段：模型文件dbu_error.ps.c。
计算方法：与点对点链路的计算方法一致，根据误码率计算误码数目。 6） 纠错阶段：模型文件dbu_ecc.ps.c。