扫一扫,微信关注我们
品牌 | Siemens/德国西门子 | 应用领域 | 化工,电子,电气 |
---|---|---|---|
产地 | 德国 | 品牌 | 西门子 |
西门子驱动模块6SL3120-1TE24-5AA3
直接从用户程序中发送认证电子邮件。电子邮件客户端设计有通知功能,可以在控制程序中直接通知用户。
通过FTP进行通讯;
大多数操作系统平台都可以使用的开放协议
设计有30 MB RAM文件系统,可以用作动态数据的中间存储器。
S7-300 PROFINET CPU集成有Web服务器。因此,标准Web浏览器可以读出S7-300站中的信息:
CPU一般信息
诊断缓冲区的内容
变量表
标签状态
模块的状态
报文
工业以太网的相关信息
PROFINET节点的拓扑结构
等时模式
使用系统功能“同步模式",可以同步耦合
分布式信号采集、
PROFIBUS信号传输和
程序执行
总线周期时间的程序运行。
创建了自动化解决方案,可以以固定间隔时间(常量总线周期时间)捕捉并处理输入和输出信号。同时创建了前后一致的部分过程图像。
借助常量总线周期时间和分布式I/O同步信号处理技术,S7-300确保可以地重现规定的过程响应时间。
为同步模式系统功能提供了极为丰富的支持组件,可以处理运动控制、测量值采集和高速控制等领域的苛刻任务。
在分布式自动化解决方案中,目前的SIMATIC S7-300开始涉足重要的高速加工处理应用领域,并确保可以获得的和可重现性。这意味着可以以稳定的产品不断地扩大生产数量。
模块的诊断和过程监视
SIMATIC S7-300的大量输入/输出模块都具有智能功能:
信号采用的监控(诊断)。
监控来自过程的信号(硬件中断)。
诊断
诊断功能可以用来判断模块的信号采集(针对数字量模块)或者模拟量处理(针对模拟模块)是否工作于*状态。在诊断分析中,必须区分可参数化和非参数化诊断消息:
可参数赋值的诊断报文:
仅由合适的设定参数启用之后才会发出诊断消息。
不可参数赋值的诊断报文:
这些消息的发出是一个常规事件,即该过程与参数化无关。
如果某个诊断消息处于状态(例如“无传感器输入"),则模块会发起一个诊断中断(若已经为该诊断消息设置了参数,则仅在相应的参数化过程之后才会产生中断)。CPU会中断用户程序或较低优先级任务的执行,并接下来执行相关的诊断中断块(OB 82)。
数字量输入/输出模块
诊断报文
可能的故障原因
无传感器输入
传感器输入过载
传感器输入至M之间存在短路
无外部辅助电压
模块无L+电压
无内部辅助电压
模块无L+电压
内部模块保险丝故障
保险丝烧断
内部模块保险丝故障
模块中的参数不正确
传输到模块的参数不正确
时间监控功能已经编址(看门狗)
高电磁干扰
模块故障
EPROM故障
高电磁干扰
模块故障
RAM故障
高电磁干扰
模块故障
硬件中断丢失
硬件中断到来的速度超过了CPU的处理能力
模拟量输入模块
诊断报文
可能的故障原因
无外部负载电压
模块无L+负载电压
组态/参数化错误
传输到模块的参数不正确
共模错误
输入(M-)之间的UCM电压差和测量回路(MANA)的参考电压过高
断路
传感器回路的电阻过高
模块和传感器之间的连接线出现断路
通道未切换(开)
低于测量范围的下限
输入值低于正常范围,可能因故障所至
量程为4至20 mA,1至5伏:
传感器极性接反;
量程选择错误
其它量程:
量程选择错误
高于测量范围的上限
输入值超出量程
模拟量输出模块
诊断报文
可能的故障原因
无外部负载电压
模块无L+负载电压
组态/参数化错误
传输到模块的参数不正确
M短路
输出过载
输出QV至MANA短路
断路
执行器电阻过高
模块和执行器之间的连接线出现断路
西门子驱动模块6SL3120-1TE24-5AA3
为保证系统稳定运行,系统CPU应避免长时间满负荷运作,应用程序CPU占用不宜过高。客户需要在调试阶段监测应用程序各个进程线程占用情况,对占用过高的进程线程进行优化。因CE自身不带进程线程系统占用查看工具,我们增加了AppHelper助手工具方便客户使用。
在之前的技术文章《CE应用程序助手简介》中简单介绍过英创AppHelper应用程序助手,本文将详细介绍AppHelper的使用方法。
AppHelper查看方法
客户在自制底板上只要引出了网络,USBOTG,DEBUG调试串口,或板子其它串口任意之一便可以查看AppHelper信息。
网络方式
通过telnet登录上板子,运行命令sysinfo,即可获得AppHelper打印的进程线程信息。
telnet模式打印示例图
USBOTG方式
使用AHC工具(使用方法见本文下一节)配置AppHelper输出为COM1。连接上板子USBOTG口,板子将以虚拟串口形式被PC识别。使用任意串口工具向该串口输出任意三个字符(任意波特率),即可获得AppHelper打印的进程线程信息。
USBOTG,DEBUG及其它串口打印示例图
DEBUG调试串口方式
使用AHC工具(使用方法见本文下一节)配置AppHelper输出为DEBUG。连接板子的DEBUG串口,PC端使用任意串口工具,设置波特率115200,向DEBUG口输出任意三个字符,即可获得AppHelper打印的进程线程信息。
串口方式
将底板上引出,且客户应用程序未使用的串口连接上PC。使用AHC工具(使用方法见本文下一节)配置好串口号及波特率。PC端使用任意串口工具,用设定的波特率向该串口输出任意三个字符,即可获得AppHelper打印的进程线程信息。
AHC工具使用介绍
AHC工具即AppHelper Config工具,用于设置AppHelper打印信息的输出位置。有两种办法进行设置。
控制面板方式
在板子控制面板中运行AHC工具。
选择好输出信息的串口及波特率(其中COM1为USBOTG),点击OK键保存配置,板子重启后配置生效。
telnet方式
通过telnet登录上板子,执行命令AHC port [baud]
参数port:串口号,值为0-6,0表示DEBUG串口,1表示USBOTG转虚拟串口,2-6分别表示板子的COM2-COM6。
参数baud:波特率,可选参数,如果不填表示保持原波特率,支持1200,2400,4800,9600,19200,38400,57600,115200。当port为0时,baud固定为115200,当port为1时,baud值不生效。
命令执行后,DEBUG口可以看到打印提示信息。
打印格式说明
打印结果为数行,其中每行的格式均为:类型 ID号 占用情况 名称
以下图一次打印的部分截图为例:
类型
PID表示为process进程。TID表示为上面进程下的thread线程。
ID号
即进程ID值或线程ID值。
占用情况
显示格式为 K n% U m% total%
n值为该进程或线程在Kernel系统层的占用
m值为该进程或线程在User用户层的占用
total值为总占用,它应当等于n+m的和
进程下各个线程total占用和应当等于进程的total占用
名称
进程名即EXE的名称,线程默认没有名称,下一节会介绍如何给线程命名,从而能在AppHelper中显示出来。
进程及线程监视说明
AppHelper会打印系统下所有的进程的CPU占用信息。
只有在\NandFlash目录下的exe生成的进程会额外打印出它下面所有线程的CPU占用信息。
默认情况下,生成的线程只有ID号,没有名称,如果线程较多会不便于查看。我们可以通过简单代码给线程命名。
以光盘里的串口例程SPT_HEX为例:
添加一个结构体的定义
typedef struct _THREAD_INDEX
{
DWORDdwSize;
DWORDdwThreadID;
TCHARszThreadName[32];
_THREAD_INDEX*pNext;
}THREAD_INDEX;
在创建线程后给线程命名
这里把串口接收线程命名为"CommRecvTread"
hRecvThread = CreateThread(0, 0, CommRecvTread, this, 0, &m_dwTID);
HANDLE hHLP;
DWORD dwLen;
hHLP = CreateFile(L"HLP1:", GENERIC_READ | GENERIC_WRITE, 0, 0, OPEN_EXISTING, 0, 0);
THREAD_INDEXthreadIndex;
wsprintf(threadIndex.szThreadName, L"CommRecvTread");
threadIndex.dwThreadID = m_dwTID;
threadIndex.dwSize = sizeof(THREAD_INDEX);
WriteFile(hHLP, &threadIndex, sizeof(THREAD_INDEX), &dwLen, NULL);
CloseHandle(hHLP);
在结束线程后取消命名
线程结束后应当手动将命名取消掉,避免不必要的显示错误,设置线程名为空,即可取消原命名。
HANDLE hHLP;
DWORD dwLen;
hHLP = CreateFile(L"HLP1:", GENERIC_READ | GENERIC_WRITE, 0, 0, OPEN_EXISTING, 0, 0);
THREAD_INDEXthreadIndex;
wsprintf(threadIndex.szThreadName, L"");
threadIndex.dwThreadID = m_dwTID;
threadIndex.dwSize = sizeof(THREAD_INDEX);
WriteFile(hHLP, &threadIndex, sizeof(THREAD_INDEX), &dwLen, NULL);
CloseHandle(hHLP);
命名线程后再使用AppHelper查看,启动接收线程后,就可以看到CommRecvTread这个线程,另外个没有命名的线程为SerialPort程序的主线程。