- Java锁的逻辑(结合对象头和ObjectMonitor)
- 还在用饼状图?来瞧瞧这些炫酷的百分比可视化新图形(附代码实现)⛵
- 自动注册实体类到EntityFrameworkCore上下文,并适配ABP及ABPVNext
- 基于Sklearn机器学习代码实战
上一篇我们学习了 SECS-II 协议,对 SECS-II 协议有了初略的了解,现在我们再来一起学习 SECS-I 协议.
文章的内容基本上来自参考资料和自己看的文档,若有侵权,请联系删除,谢谢.
SECS-I属于传输协议标准,主要定义了电气规格、传输速度、交握码等物理信息.
注意,1、SECS-I 基础介绍 这一段内容主要是参考 SECS半导体设备通讯-1 SECS的基本概念 文章,但是内容加上了自己的理解以及看到的其他资料,所以与原文对比是有出入的。这段内容对 SECS-I 有一个初略的介绍,后面的内容来源自己查找的资料,对 SECS-I 有一个更加深入的介绍。因为本小节的内容主要参考 SECS半导体设备通讯-1 SECS的基本概念 ,特在此说明.
SECS-I 定义了使用 RS-232 作为传输媒质时 点到点的数据通信 。实际的传输 由8位Bit连续发送,有一个开始位和一个停止位.
通信是 双向和异步的,但是同一时间只能有一个方向的数据进行传输 。 方向由特殊字符和握手建立 ,然后发送数据本身.
注意这里 1 上面的是 lsb .
数据被分块进行传输, 每个数据块最大为 254 字节 。一个消息是一个方向完整的通信单元,由1到32,767个块组成。每个块标头都包含用于标识该块作为特定消息的一部分的信息.
一个Block 包括 一个Length Byte、N Data Bytes 和 CheckSum .
N Data Bytes
的校验和; Data Bytes 由 10 byte Header 和 Message Data 组成:
编码后的 SECS-II 消息构成
; 10 byte Header 由 4个内容组成,其中:
第一个比特为 R-bit
,其作用是指出消息传输的方向。 第一个比特为 Wait-bit
,用于指示消息的发送者是否需要回复。 第一个比特为 End-bit
,用于指示这个是否是消息的最后一个块。 第七和第八字节表示 source ID,用于表示消息的发送者,第九和第十字节表示 transaction ID,用于唯一标示每个发送的消息
。 我们一起看看 Block 的组成:
我们一起看看 Header 的组成:
这里的 Upper Device ID 是指:
块的传输过程,先传输块的长度,再传输块,最后发送校验码.
标准建议每次可传输的Date Bytes字节最多为254,如果一个消息的大小<245个字节,则以一个块的形式进行传输。如果一个消息的大小> 245个字节,则以分块的形式进行传输.
从上图中,我们可以得知,SECS-I 使用的是块传输协议.
块传输协议 用于 建立通信的方向 ,并为传递消息块提供环境。主消息或回复消息可能需要多个块传输(多块消息).
看到这个,是不是想起来 TCP 建立连接时的三次握手。这里的作用是 TCP 的三次握手差不多,用于确认通信双方已经准备就绪。那接下来我们一起看看 Block Transfer Protocol 的握手顺序是怎么做的.
Block Transfer Protocol 中的握手顺序是 主机和设备 之间的 字节交换 .
那既然是 字节交换 ,交换的是哪些字节的呢?
Handshake Codes (握手码):
有四种 握手码。它们用于控制块传输协议中的数据流。下表展示了这四种握手码 。
Handshake Codes | Hex Value | 描述 |
---|---|---|
ENQ | 05 | Ready to Send |
EOT | 04 | Ready to Receive |
ACK | 06 | Correct Reception |
NAK | 15 | Incorrect Reception |
SECS-I Parameters :
用于在实现块传输协议时定义一些边界。下表显示了SECS-I参数:
SECS-I Parameters | 描述 |
---|---|
T1 | Inter-Character Timeout |
T12 | Protocol Timeout |
RTY | Retry Limit (最大重试次数) |
Master/Slave | Resolve contention (解决争论) |
Is the time between receiving each character (after receiving the first character) in the BLOCK DATA 。
Is the time between sending the ENQ and receiving the EOT 。
This defines the number of times to initiate the block transfer (start sending with the ENQ.) Upon the receipt of a NAK (or other protocol error), the RTY value is adjusted and the block transfer is again attempted. 。
Is used to resolve contention. The host is slave and the equipment is the master. Contention is when both the host and the equipment attempt to communicate at the same time. The following shows how contention is resolved 。
块数据是单块或多块消息的数据部分。它包含 一个Length Byte(长度字节), N Data Bytes(N个数据字节)和a two byte Checksum(一个两个字节校验和) .
下面这张图很重要,一定要看懂,不然不知道 Block Data 是怎么组成的,自己写代码的时候,也会一脸懵逼.
接下来,我们对上面的图进行逐一的讲解:
第一个字节
。它是N个DAta Bytes(10 Byte Header + Data Structure)中的字节数。两个字节校验和不包括在这个计数中,值范围为10到254字节。这里要注意的是, Length Byte 占用一个字节
。 Is the first byte sent in the Block Data. It is the number of bytes in the N Date Bytes (10 Byte Header + Data Structure). The two byte Checksum is not included in this count The value ranges from 10 to 254 bytes. 。
– Is the data portion of the message block. It contains a 10 Byte Header, and the Message Data. The size ranges from 10 bytes to 254 bytes. The minimum size of N Data Bytes is 10 (contains only the 10 Byte Header), and the maximum is 254. 。
Is the data portion of the message. It contains all or a portion (if a multiblock message) of the encoded SECS-II. 。
每个消息都包含一个报头。标头用于描述包含在块数据中的数据。它包含 Device ID, Message ID, Block Number, and System Bytes(设备ID、消息ID、块号和系统字节) 。其他重要指标也包括在内.
接下来,我们一起来看看 Header 的 4 个组成部分:
Bytes 1 and 2 of the header are the device ID. The left byte is the upper device ID, and the right byte is the lower device ID. The left most bit of the left byte is the reverse bit (R-bit). The R-bit determines the direction of the message. 。
Bytes 3 and 4 of the header is the message ID. The left byte is the upper message ID, and the right byte is the lower message ID. The left most bit of the left byte is the Wait bit (W-bit). The W-Bit is used to indicate that the sender of the primary message is expecting a reply. 。
The message ID indicates the SECS-II stream and function. The upper message ID is the stream, and the lower message ID is the function. 。
如果还记得上一篇文章中,描述 Streams and Functions 取值范围, Stream 的取值范围是 0 ~ 127。因为 strem 的MSB 是 W-bit,用于表示是否期望得到回复。 Function 的范围是 0 ~ 255.
报头的第5个字节和第6个字节表示块号。左字节是 upper block number,右字节是 lower block number。左字节中最左边的位是结束位(E位)。E位表示这是否是消息的最后一个块。
当发送的消息需要多个块时,将使用多块消息。每个块都是数字并且是有序的(这里的数字应该指的是块的序号)。由于消息的接收者不知道一共发送了多少个块,所以使用 e位 指示当前块是不是最后一个块,不会最后一个块的话,后面还会有块发送过来。多块消息中的最大块数为32,767个。
Bytes 5 and 6 of the header is the block number. The left byte is the upper block number, and the right byte is the lower block number. The left most bit of the left byte is the end bit (E-bit). The E-bit indicates this is the last block of a message. 。
A multi-block message is used when the sent message requires more than one block. Each block is number and sent in order. Since the receiver of the message does not know how may blocks to expect, the E-bit indicates which block is the last, or if there are more bocks to follow. The maximum number of blocks in a multi-block message is 32,767. 。
system bytes(系统字节)
。左边的两个字节是 source ID(源ID)
,右边的两个字节是 transaction ID
(事务ID)。源ID标识消息的发送方,并用于消息路由。事务ID标识该消息,并且对于所发送的每个消息都是 唯一的
。在其关联应答处的主消息具有相同的(匹配的)系统字节。最后一句话如何理解呢?它的意思是,回复的消息的 System Bytes 和 发送的消息的 System Bytes 是相等的。 The last four bytes of the header are the system bytes. The left two bytes are the source ID, and the right two bytes are the transaction ID. The source ID identifies the sender of the message and is used for message routing. The transaction ID identifies the message and is unique for each message sent. A primary message at its associated reply have the same (matching) system bytes. 。
上面我们对 SECS-I 使用到的 Block Transfer Protocol 有了初略的了解。接下来,一起看看 如何发送 S1F1 指令,以及对应的回复指令 S1F2.
下面显示了在发送 primary message 和接收 secondary reply message 时传输的字节。这不是一个多块的消息。主机发送S1F1,设备发送S1F2应答.
这张图及其重要,对理解 block transfer protocol 特别重要,理解了这张图,对 SECS-II 和 SECS-I 算是有一个入门的了解了.
这一节内容我们将一起看看 Typical SECS Protocol Parameters(典型的SECS协议参数) .
下面是 SECS-I / SECS-II 协议参数的摘要集,以及一些典型的值.
Parameter | Function | Typical value |
---|---|---|
Baud (波特率) | Rate Serial line speed | 9600 |
Device ID | Identifier assigned to equipment (分配给设备的标识符) | 0 |
T1 | Inter-Character Timeout | 1 (second) |
T2 | ENT / EOT Timeout | 10 (seconds) |
T3 | Reply Timeout | 45 (seconds) |
T4 | Inter-Block Timeout | 45 (seconds) |
RTY | Retry Limit | 3 |
M / S | Master / Slave | Host-Slave Equip - Master |
参考资料:
SECS半导体设备通讯-1 SECS的基本概念 。
最后此篇关于03、SECS-I协议介绍的文章就讲到这里了,如果你想了解更多关于03、SECS-I协议介绍的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
我已经包含了在我的 html 页面中显示我的页面中的用户名。 我还找到了显示相同的内容。 我需要知道的是,这些方法之间从 LDAP/DB 中选取用户名的方式是否有区别?哪种方法可以保持最佳响应时间?
情况:我使用(php)cronjob 来保持我的数据库最新。受影响的表包含大约 40,000 条记录。基本上,cronjob 会删除所有条目并随后插入它们(具有不同的 ofc 值)。我必须这样做,因为
每个与 sec:authentication="..."无论是否登录都会显示。甚至是明确的false导致div出现。 另一边与sec:authorize="..."即使有明确的 true 也是隐藏的.
我正在关注 rfc6455 : Concretely, if as in the example above, the |Sec-WebSocket-Key| header field had the
Timespan(0,0,secs) 和 Timespan.FromSeconds(secs) 的返回值有区别吗? 在我看来,不同之处在于 FromSeconds 接受 double。 最佳答案 最终
美好的一天,就我而言,一切都很好,并且在 localhost ide 上运行良好,但在 linux thymeleaf 下的站点上 sec:authorize 和 sec:authentication
我有一个 UIView 子类,在某些情况下我需要改变它的颜色一段时间,比如 5 秒,然后再改变颜色,我使用的方法是 performSelector:afterDelay: 和我传入的选择器是将颜色改回
测试之间的唯一变化是更改 TLS 版本。 Chrome 和 FireFox 之间的行为是相同的。 TLSv1 和 TLSv1.1 均达到 90 兆字节/秒。他们在 Java 6 (TLSv1) 和 J
我在数据框中有一个时间详细信息作为文本。 dict1={'time' : ['2 min 19 sec','2 min 43 sec','1 min 33 sec','32 sec','40 sec'
这里我们先学习 SECS-II 协议,给我的感受是先学完 SECS-II 协议,再去学习 SECS-I 和 HSMS 协议更加容易理解,所以这里我先介绍 SECS-II 协议。 文章的
03、SECS-I 协议介绍 上一篇我们学习了 SECS-II 协议,对 SECS-II 协议有了初略的了解,现在我们再来一起学习 SECS-I 协议。 文章的内容基本上来自参考
这里的 super 新手有一个 friend 帮助我制作了这个用于查看对冲基金 13fs 的网络爬虫。之前它运行良好,但最近我遇到了这个错误: response_two = get_request(s
我想创建一个条形图,其中 y 轴使用“min:sec”作为标签。但是,我要显示的数据以秒为单位。现在最好的方法是什么? zone time_in_zone 1 305
文件名first.java package p1; public class first { int a; public void display() { System.out.pri
我正在尝试读取和存储名为xx.sec.gz.的文件。正在下载该文件很好,但是其中存在的数据完全不同(无法读取)。我使用了retrbinary .....除了retrbinary之外,python中存在
class Win32_PerfRawData_Tcpip_NetworkInterface : Win32_PerfRawData { uint32 BytesReceivedPerSec;
我试图在 Matlab 中绘制一些关于分钟而不是秒的数据作为格式化时间,即 min.sec。 我有实时数据流,在收到每个样本的地方,它的时间以秒为单位也被发送。然后我根据时间绘制它们。现在,由于我的
我在这里面临一个棘手的情况。我有一个基于 java 的应用程序,它试图通过 scp 远程机器复制某些文件。在执行这些任务时,我从应用程序端发现以下错误消息。 scp protocol error mt
我创建了一个弗兰肯斯坦式的音频播放器,并且在轨道计时方面需要一些帮助。我现在有了它,所以它从 0 开始计数 -> 无论轨道时间是多少,以秒为单位。我似乎不知道如何将这些秒转换为分钟:秒。 我是使用 J
我有一个带有以下 View 代码的Spring + Thymeleaf项目。 Contacts Welcome to the site! Wrong us
我是一名优秀的程序员,十分优秀!