首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > 嵌入开发 > 单片机 >

电力实时采集系统实时性的几个小问题

2013-11-23 
电力实时采集系统实时性的几个问题我想用一个采集器实时采集至少36块电表的6项数据:三项电流,总有无功率,

电力实时采集系统实时性的几个问题
我想用一个采集器实时采集至少36块电表的6项数据:三项电流,总有无功率,频率这几个相,在1s时间内能全部采集完这36块表吗?不行的话怎么改进?我这个方案可行吗? 电力
[解决办法]

引用:
97 07 协议里面的电表反映时间是这么写的20ms<=Td<=500ms

如果这个协议,个人认为不可能.
只要是直接与电能表通讯的情况下
反应时间,协议规定那呢 (20+岁的协议了
传输时间,这个和物理层关系很大,
轮询时间,如果串口(假设)少于36个的话,(呵呵
重传,掉线:如果没有电表/掉线.协议规定还有重传等等机制,(额
各种特色的厂商特别的规定.

个人的保守估计:10秒.已经是个人认为的极致了.

其实这方面完全没有如此高实时性要求(本来就不是*实时*).如果真需要实时,可能根本就不使用"电表"这种东西咯.

[解决办法]
基本不可能,这样算,按9600(一般集中器的最大波特率了,大多用1200,2400)算,1S其实就是交换1000左右的字节,电流2到3个字节,功率2个字节,频率2个字节,这样只是有效数据就至少12个字节了,那么如果是modbus协议,一来一回至少要30个字节(前提是这几个数据量是地址连续)。30*36=1080,而且每个表之间你还需要一些空闲,所以不可能1S完成,保险点的方案是1分钟读完36个表。另外,如果用645规约就要更多的时间。

[解决办法]
引用:
Quote: 引用:

Quote: 引用:

行不行先试试再说,行不通找原因再改进。
这个N B了。。。

怎么了嘛,多少也得要自己试试再说吧。
又不是涉及什么未知理论,只是一个实际产品。前期的可行性评估就可以覆盖产品的软、硬件架构设计可行性了,还等你做出来试?记得多年前一个兄弟项目组做LTE的项目方案,还没到LTE的协议栈设计编码呢,就需要前期估算出数据率在满速100M时的MIPS,进而确定方案选型,该选多快的处理器,该用多大的FLASH,RAM,诸如此类。很多时候,这种实际的产品只是理论的一个验证而已。设计之前,必须想好七八十的技术细节,确定一些技术关键点是没有问题的,然后放手去做就OK了。无非只是个实现而已。

热点排行