C#如何持续地监视外部信号？

[电动飞机制造商]

我是做PLC开发的，主要是操纵硬件。举个例子来说，X轴马达往前走，遇到传感器SB1，就停下来。这个SB1就必须处于持续的监控状态，程序不能以周期的方式去读这个SB1的状态，否则，在上一个读取SB1的行为结束，下一个读取SB1的行为还没有到来的时候，SB1被触发了，而程序却不知道，则X轴马达就会冲过去，造成机器损坏。
PLC本身能持续地监控传感器，不需要额外编程，用户只要把SB1与X轴马达关联起来即可；SB1被触发了，X轴马达就会停机。
而C#上位机其实是监控PLC里的某个位的，比如M100.0。M100.0与SB1关联起来。SB1从1变成0，M100.0也会从1变成0；反之，SB1从0变成1，M100.0也会从0变成1。
因此，C#只要监视PLC里的M100.0即可，这种监视是持续的，只要M100.0一有变化，C#就能知道，并且做出响应。
请问，这种持续的监视怎么做?
Ps: 想过用While(true)，感觉不大好

[X-i-n]

如果只是单纯监控信号，要么轮询，要么用中断（取决于控制器的SDK）。在任何场景里，都要把上位机软件当成一种不可靠的对象去考虑。它会死机，会报错，会异常退出，甚至压根没在运行。越是底层的控制需求，越是要用控制器或者PLC去处理。

[wanghui0380]

你陷入一种误区 信号采集归信号采集和语言无关 你也无须纠结什么while（ture）不while（ture） 本身信号传输就推拉两类。下面的肯推给你，你无需折腾。只是标准的串口，tcp通讯 下面的不给推，非让你自己拉。当然就是定时拉，你绕不过去。 哪怕你采用一个硬件采集卡，其实就像楼上说的一样，那个还是轮询+中断 应该做什么就做什么，无需跟那个园子学纠结。 如果你实在要纠结什么我就是不要无限循环，那也行把。 1.换C++写驱动，直接下定时中断 2.加挂硬件采集卡，让采集卡直接硬件给你做采集（把你说纠结的循环交给硬件去玩） 3.中间接opc，把你的采集交给opc去采集

[以专业开发人员为伍]

首先要说，.net 现在早就是“异步编程的经典”工具了，你可以编写异步且主动“死”循环的代码，例如

public async void 开始监视SB1()
{
    while(stopFlag)
    {
        读取状态并处理();
        await Task.Delay(150);
    }
}

不懂 async void 这个语法就需要学习、否则就无法跟上我们开发的节奏了。 其次，从底层来说，良好的“监控”需要双向设计通讯协议。也就是上位机发送一个或者几个特定含义的召唤命令，然后下位机反馈消息。如果你不设计合适的信令消息，那么路边摊是做不出工匠的瓷器活儿的。

[以专业开发人员为伍]

.net （包括 vb.net 等等，以及 Blazor Assembly在网页上运行的 c# 程序）现在都是支持 .net 各种大型异步微任务（Task）编程的，可以轻松编写高性能的（准）实时异步算法的系统。这个需要及早将知识升级换代。我们面试 c# 程序员都很少仅仅面试传统的数据结构、算法问题了，更多地看类似 Linq、Task、Actor设计模型等等知识的运用。 而从通讯角度看，许多人的盲点更多。编程要“亲自设计信令”，自己动手设计消息的规范，并且亲自编写解析代码，调试报文交互过程，测试应用客户端使用通讯接口之后的性能改善。自己养大的孩子才真的会重视起来通讯层设计得不好对应用的干扰。

[以专业开发人员为伍]

一般的 PLC 通讯，遵循某种比较好一点儿的工业协议，上位机首先发送一个“监控”指令，例如通知下位机传送某些地址的数据，那么下位机就会在这些地址的数值发生改变时主动发送一条消息给上位机。这就是双向的协议。在基本的编程语法之外，这其实是个设计理念问题，说“架构”有点太“大”了，这类东西不用什么架构师，在控制方面做过设计的专业程序设计师即可。

[兔子-顾问]

用什么通讯的，串口？USB？网络？ 单独做一个上位机程序，数据缓存的线程接收和分包，事件方式推送到界面或处理程序。 标准的上位机软件开发而已，不明白你为什么放着PLC那么多好用的软件工具不用，非要用c#来写，而你似乎又不太会写。要不外包给我算了

[电动飞机制造商]

引用 1 楼 兔子党逍遥 的回复:

用什么通讯的，串口？USB？网络？ 单独做一个上位机程序，数据缓存的线程接收和分包，事件方式推送到界面或处理程序。 标准的上位机软件开发而已，不明白你为什么放着PLC那么多好用的软件工具不用，非要用c#来写，而你似乎又不太会写。要不外包给我算了

我这是在学习。触控屏当然会了，而且会好几种

[X-i-n]

发送一个运动命令之前，检测当前电机的运动状态，如果处于停止状态就发送，如果正在运动，就不发送，同时给用户返回一个提示。

[xuzuning]

持续地监视外部信号？连可能产生信号的设备是否在运转都不能保证，怎么监视？

[weixin_42066565]

回帖test

[luj_1768]

这种需求可能应该分层处理，单层结构性能不好。while语句可能不太适合，可以考虑使用do-loop 循环。

[牧童吃五谷]

用PLC自己编程处理控制逻辑，不需要用C#处理控制逻辑的，PLC处理控制逻辑一般可以在10毫秒内完成处理，你采用C#应该是不可能对SB1的动作反应得过来的。对于人机界面可以考虑使用一个监控组态软件，你这个单机版本的监控组态软件也就几百块，熟悉开发流程了应该半天搞定。 监控组态软件可选Wincc,iFix,iSeez,KingView,ForceControl等等

[HighPC]

看设计实时性的东西还是 PLC。现在讨论的C#只是表现层的东西，因此只要独立一个线程后台循环跑就好。既不影响响应，也看着还好。

[HighPC]

11楼建议也不错，当然怕蛮烦就用组态，现成的驱动。

[Alvin-G]

[quote=外包给我算了[/quote]

[一线Jon]

引用 楼主 电动飞机制造商 的回复:

我是做PLC开发的，主要是操纵硬件。举个例子来说，X轴马达往前走，遇到传感器SB1，就停下来。这个SB1就必须处于持续的监控状态，程序不能以周期的方式去读这个SB1的状态，否则，在上一个读取SB1的行为结束，下一个读取SB1的行为还没有到来的时候，SB1被触发了，而程序却不知道，则X轴马达就会冲过去，造成机器损坏。 PLC本身能持续地监控传感器，不需要额外编程，用户只要把SB1与X轴马达关联起来即可；SB1被触发了，X轴马达就会停机。 而C#上位机其实是监控PLC里的某个位的，比如M100.0。M100.0与SB1关联起来。SB1从1变成0，M100.0也会从1变成0；反之，SB1从0变成1，M100.0也会从0变成1。 因此，C#只要监视PLC里的M100.0即可，这种监视是持续的，只要M100.0一有变化，C#就能知道，并且做出响应。 请问，这种持续的监视怎么做? Ps: 想过用While(true)，感觉不大好

正常来说就是在线程中用 while (true)

[x县豆瓣酱]

这压根不该是上位机管的东西，它也管不好，它除了以最快速度去扫再也没有别的办法，应该是到位了plc发消息给上位机。

[x县豆瓣酱]

如果真要无限扫那就是while（true），无论你怎么包它最终里面就是这个原理呀

[楚笑sama]

这种东西C# 扫描不过来的 一般是PLC来通知 你要么是PLC里写一个SOCKET服务，c#来连接，状态改变后你通知c#程序
而且据我所知 如果你用西门子1200以后的PLC 他本身就内置了OPC ，OPC可以做到量变通知，c#端只要做好点的监听就行

[Moosu]

楼主感觉搞错了一个概念，上位机一般来说是不会直接参与设备的直接控制。都是由专门控制器（如PLC）进行数据采样，并进行逻辑控制。还有就是通讯这块，尤其是下位机数据处理周期（逻辑处理与采样周期）与上位机读写的数据通讯周期。这两个东西一般来说不是一个量级的，按照你的意思要用C#参与控制，我个人觉得你可能需要自己单独用一个采样板卡再自己写驱动了，但是真的这样做的话，这跟做一个下位控制器差别感觉就不大了。