运动控制器十大品牌（个人观点） 点击：46273 | 回复：65
对：征 关于
请教，实时操作系统的响应是多少？
Vxwors是业界公认的强实时操作系统， 广泛用于航天，工业控制等，Vxwork的时间片是10ms， 之所以实时是靠硬件处理，即系统采用对外围的控制周期很短的外设采用外围单板等硬件处理， 然后通过PCI等总线进行信息交互，从而达到高速的实时处理。但这个实时处理主要是靠硬件来完成的。
如果不采用在PCI总线上的硬件处理方式， 如果也没有采用印鉴中断处理多方式， 而是采用操作系统的纯软件处理， 响应会很慢， 绝对满足不了工控等的时限要求。
才用中断处理时， 对中断响应来说， 跟操作系统无关， 中断的优先级都高于任务， 并且中断的堆栈是直接在当前任务上进行堆栈， 不需要任务切换。 换而言之，如果不带操作系统的硬件中断响应达不到200us， 用什么样的实时操作系统也达不到200us。用操作系统在中断处理的模式下能够达到200us， 如果不带操作系统的处理程序响应是会达到小于等于200us的响应周期， 即性能高于带操作系统的。
如果在操作系统上采用基于PCI总线的硬件处理方式，其实时性能由硬件决定，跟操作系统无关。 如果采用单片机+CPLD的处理方式， 性能相差不大。
之所以采用实时操作系统， 最大的优点不在于实时响应。请搞清楚这个问题。
1、Windows上的SoftPLC包括KW Multiprog, 3S CoDeSys和Infoteam OpenPCS是如何实现实时的？
2、IntervalZero公司的RTX又是什么原理？
3、Beckhoff的TwinCAT和EterCAT是如何实现100us的控制周期的？
4、Soft Servo System和NI公司的Soft CNC和Soft Motion又该怎么解释？
内容的回复：诚心请教：
我对这些品牌不熟悉，西门子的略有了解，硬实时的都是在总线上外扩处理硬件或处理器实现的。
至于windows 等，可以这样理解：其功能是靠外置或内置的运动控制卡实现的。就相当于在PCI总线上外扩一个带有控制器的控制系统，这个控制板卡的命令源是由WINDOWS的给定的，但对于单轴的闭环控制由板卡的处理器完成，这个控制周期可以很短，跟操作系统无关。
如果纯粹基于操作系统的中断处理（操作系统的tick为10ms）， 如果中断达到小于ms级别并且具有严格的实时要求，此时操作系统的CPU完全用于进行中断处理， 即操作系统的任务完全没法运行， 这样的操作系统完全没有意义。
所以对于时限固定小于10ms并具有严格时限要求， 如运动控制系统的位置控制（200us）， 采用目前的任何一种实时操作系统的纯中断或者任务处理是实现不了的，只能在系统总线上外挂处理器或者硬件处理。
所有的系统框架基本都是这个原理，只不过实现不同而已。
希望能给你一点借鉴。
我对这些品牌不熟悉，西门子的略有了解，硬实时的都是在总线上外扩处理硬件或处理器实现的。
至于windows 等，可以这样理解：其功能是靠外置或内置的运动控制卡实现的。就相当于在PCI总线上外扩一个带有控制器的控制系统，这个控制板卡的命令源是由WINDOWS的给定的，但对于单轴的闭环控制由板卡的处理器完成，这个控制周期可以很短，跟操作系统无关。
如果纯粹基于操作系统的中断处理（操作系统的tick为10ms）， 如果中断达到小于ms级别并且具有严格的实时要求，此时操作系统的CPU完全用于进行中断处理， 即操作系统的任务完全没法运行， 这样的操作系统完全没有意义。
所以对于时限固定小于10ms并具有严格时限要求， 如运动控制系统的位置控制（200us）， 采用目前的任何一种实时操作系统的纯中断或者任务处理是实现不了的，只能在系统总线上外挂处理器或者硬件处理。
所有的系统框架基本都是这个原理，只不过实现不同而已。
希望能给你一点借鉴。
楼上的，不知道你所谓的“操作系统的tick为10ms”是指哪种操作系统？
并且除了时间片轮询方式，在大多数实时操作系统中，uCOSII, VXWORKS等，实时任务都是可以中断切换的；中断切换时间在us级别。由于程序负载量与执行时间相关，所以才有有些控制系统代码限制的说法。并且实时操作系统的执行效率与CPU的选型很有关系，而不能局限于某个参数（10ms或者1ms），现在的CPU的等级已经提高很多了。但是在200us的级别是完全可以做到的。
至于“采用目前的任何一种实时操作系统的纯中断或者任务处理是实现不了的，只能在系统总线上外挂处理器或者硬件处理。”这种说法，应该是值得商榷的。
并且，据说现在beckhoff的EtherCAT二代产品也能够做到250us的控制周期，不仅仅是总线周期，而是控制周期。而Beckhoff据说也是采用的RTX实时内核（可以在windows环境下）。一般来讲通过现场总线的方式会比采用内部总线（因为内部总线有时候会采用并行通讯）来得慢。连通过带操作系统的以太网通讯都能达到250us的控制周期了，那么通过操作系统的本地总线运动控制芯片那更加是没有问题的了。
以上给你做参考。
对：好色源自本色 关于引用征 的回复内容：
我对这些品牌不熟悉，西门子的略有了解，硬实时的都是在总线上外扩处理硬件或处理器实现的。
至于windows 等，可以这样理解：其功能是靠外置或内置的运动控制卡实现的。就相当于在PCI总线上外扩一个带有控制器的控制系统，这个控制板卡的命令源是由WINDOWS的给定的，但对于单轴的闭环控制由板卡的处理器完成，这个控制周期可以很短，跟操作系统无关。
如果纯粹基于操作系统的中断处理（操作系统的tick为10ms）， 如果中断达到小于ms级别并且具有严格的实时要求，此时操作系统的CPU完全用于进行中断处理， 即操作系统的任务完全没法运行， 这样的操作系统完全没有意义。
所以对于时限固定小于10ms并具有严格时限要求， 如运动控制系统的位置控制（200us）， 采用目前的任何一种实时操作系统的纯中断或者任务处理是实现不了的，只能在系统总线上外挂处理器或者硬件处理。
所有的系统框架基本都是这个原理，只不过实现不同而已。
希望能给你一点借鉴。
楼上的，不知道你所谓的“操作系统的tick为10ms”是指哪种操作系统？
并且除了时间片轮询方式，在大多数实时操作系统中，uCOSII, VXWORKS等，实时任务都是可以中断切换的；中断切换时间在us级别。由于程序负载量与执行时间相关，所以才有有些控制系统代码限制的说法。并且实时操作系统的执行效率与CPU的选型很有关系，而不能局限于某个参数（10ms或者1ms），现在的CPU的等级已经提高很多了。但是在200us的级别是完全可以做到的。
至于“采用目前的任何一种实时操作系统的纯中断或者任务处理是实现不了的，只能在系统总线上外挂处理器或者硬件处理。”这种说法，应该是值得商榷的。
并且，据说现在beckhoff的EtherCAT二代产品也能够做到250us的控制周期，不仅仅是总线周期，而是控制周期。而Beckhoff据说也是采用的RTX实时内核（可以在windows环境下）。一般来讲通过现场总线的方式会比采用内部总线（因为内部总线有时候会采用并行通讯）来得慢。连通过带操作系统的以太网通讯都能达到250us的控制周期了，那么通过操作系统的本地总线运动控制芯片那更加是没有问题的了。
以上给你做参考。
看看这个链接里关于任务切换的数据， 然后希望你思考一下
内容的回复：http://www.witech.com.cn/news/Article_Show.asp?ArticleID=258
如果250us的周期中断里， 进行数据计算，运算控制等占用时间为160us， 则CPU空余时间为90us。在这个空余时间里i运行操作系统及任务代码， 假设操作系统一次任务切换时间为15us， 则实际任务运行的时间为75us。
这样的设计对带有嵌入式操作系统的设备来说，在保证一个250us中断响应的情况下， 再运行操作系统CPU响应很慢， 很难满足要求， 例如外界的HMI，从文件系统读取数控程序等。
通用的做法是， 将250us的周期性中断放在带有控制器或者硬件ASIC芯片实现的单板上， 单板通过PCI（带宽133Mb）等高速总线连接到带有嵌入式操作系统的处理平台上，两个处理器采用共享内存的处理方式实现高速数据交互。
在这种架构下， 强实时的控制系统由PCI总线上的控制单板实现，数控系统的命令解析，HMI，其他辅助功能等由嵌入式处理平台实现（在这种情况下， 一个tick采用10ms的处理机制）。
从这个角度上来说， 这个250us和嵌入式操作系统没有关系。
你提到的以太网控制达到250us的问题，这个一定是通过外围带硬件控制芯片的单板挂在高速的总线上实现的数据包发送的， 纯粹靠操作系统的中断方式是不行的。现在国产的中低端千兆路由器是基于vxworks平台（10ms时间片）通过基于PCI总线的硬件单板实现的（实际达不到标称的千兆）， 在任何CPU上的以太网口在操作系统下是绝对达不到的。
还有， 冒昧的问一下， 你是做工控研发的吗？
没有别的意思， 对不是做研发的兄弟来说， 他只是看到的一个指标， 对于采用什么样的方法实现这个指标， 他完全没有概念， 所以讨论这些可能意义不大。
“还有， 冒昧的问一下， 你是做工控研发的吗？没有别的意思， 对不是做研发的兄弟来说， 他只是看到的一个指标， 对于采用什么样的方法实现这个指标， 他完全没有概念， 所以讨论这些可能意义不大。”
——感觉楼上是研发的前辈。其实我做什么到不重要，不然这个论坛里不是研发的兄弟们多着呢，总不成就不能来讨论这个问题了吧？大家就讨论讨论，在讨论中学习嘛，有错就改，只要能学到知识就好。小弟我做过几年的硬件研发，有几个兄弟开发嵌入式硬件与基于实时操作系统（UCOSII，Vxworks）开发工业控制应用软件，当然我只是初识皮毛而已。
“你提到的以太网控制达到250us的问题，这个一定是通过外围带硬件控制芯片的单板挂在高速的总线上实现的数据包发送的， 纯粹靠操作系统的中断方式是不行的。现在国产的中低端千兆路由器是基于vxworks平台（10ms时间片）通过基于PCI总线的硬件单板实现的（实际达不到标称的千兆）， 在任何CPU上的以太网口在操作系统下是绝对达不到的。”
——此说法我有疑虑，其实一般实时以太网存储数据，都会使用DMA方式，根本不占用CPU时间，运算与通讯分开执行，也并不一定需要专门外围再加硬件控制芯片（当然如果是通用的以太网芯片也属于专用芯片，那到真的一定要）。可以参考：http://www.ethercat.org/cn/ethercat.html
另外，其实Vxworks的实时性，特别是中断响应与任务执行时间与搭载的CPU等硬件规格是严重相关的，并不是一个固定的数据。
“这样的设计对带有嵌入式操作系统的设备来说，在保证一个250us中断响应的情况下， 再运行操作系统CPU响应很慢， 很难满足要求， 例如外界的HMI，从文件系统读取数控程序等。”
——针对此处，其实HMI通讯部分，实时嵌入式系统针对此也是一个任务来实现。有些是采用操作另外的一个非实时的总线协议，如Modbus，Simotion采用Profibus-dp（它的运动控制采用的是实时的Profibus-dp drive，当然这个总线的效能也不能算很好，只能怪Profibus的协议簇效率真的不是很高）。你指的很难满足要求，似乎只是你的估计而已。
“如果250us的周期中断里， 进行数据计算，运算控制等占用时间为160us， 则CPU空余时间为90us。在这个空余时间里i运行操作系统及任务代码， 假设操作系统一次任务切换时间为15us， 则实际任务运行的时间为75us。”
——您指的操作系统的实际任务是什么？指GUI？还是Windows的那些无聊的任务？嵌入式操作系统与实际移植裁剪很相关。一般专用嵌入式操作系统会将不用的功能都裁剪掉。一般这样的实时系统都会将HMI部分独立出来通过通信让另外的触摸屏之类来实现，就不占用下面的任务了。另外嵌入式操作系统却不都是实时系统。使用以太网都可以完全在250us的实时性。更何况直接CPU与直接的硬件IO。
另外，上海有一家公司在开发基于RTLinux与以太网的运动控制，就是不知道他们的参数如何，不然可以参考看看。希望能够看到国产的实时运动控制。
以上给你做参考，希望得到更多的讨论。
引用征 的回复内容：操作系统中每次中断处理完成后，退出中断时都要进行任务调度，任务调度就要花费CPU时间，对250US的周期性中断，这个任务调度占用CPU的百分比就显得很大了，因此采用外扩CPU或者ASIC等硬件来实现是很好的一种设计。 还有建议你了解一下操作系统的原理，简单的ucos系统，看完源代码后会有收获的！我不是前辈，只是做过基于vxworks的实时系统的项目，有些东西不敢瞎说
当然，你这个担心是需要的。不过事实上确实可以这么做的。任务调度占用时间其实不是很大，你做过Vxworks的项目，应该了解在不同CPU架构下，任务调度时间其实可以挺小的。再说现在动不动就是500Mhz以上的CPU，而运动控制应用上，又不做GUI，多媒体等其他部分的功能。所以使用这种方式，我倒觉得很不错。
至于你说的“因此采用外扩CPU或者ASIC等硬件来实现是很好的一种设计。”，当然，做过硬件，大家都知道使用和独立的CPU和硬件来实现速度肯定会快上很多。但是如果采用一个实时系统和一块CPU已经能够达到性能了，相信大家都不会选择再去设计硬件的。
并且硬件设计看起来简单，调试和维护，认证，售后，升级比起软件来，麻烦的不是一点点。开发周期也长很多。成本又高，人员投入也大。看看现在软件程序员和硬件设计人员的数量差异（更何况很多硬件设计的都在做开发DSP，控制系统，单片机，FPGA都偏软）有多大。
- 请教:步进电机断电后再次通电...
[9381] - 请教，把双脉冲信号改为单脉冲...[5462]
- 机械（钟表）式多圈绝对编码器...[6416]
- 伺服定位闭环控制[21146]
- 交流伺服电机的结构图[5465]
- 伺服电机转子惯量匹配问题[7353]
- 松下伺服的惯量比问题，请教！...[15685]
- 求助“分度盘工作原理”？[6127]
- 伺服电机为什么不能直接接交...[6524]
- 求助：EM253与安川连接方法[5580]
官方公众号
智造工程师
-
客服
-
小程序
-
公众号
工控网智造工程师好文精选
