我是做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)，感覺不大好
uj5u.com熱心網友回復：
用什么通訊的，串口？USB？網路？單獨做一個上位機程式，資料快取的執行緒接收和分包，事件方式推送到界面或處理程式。
標準的上位機軟體開發而已，不明白你為什么放著PLC那么多好用的軟體工具不用，非要用c#來寫，而你似乎又不太會寫。要不外包給我算了
uj5u.com熱心網友回復：
我這是在學習。觸控屏當然會了，而且會好幾種
uj5u.com熱心網友回復：
發送一個運動命令之前，檢測當前電機的運動狀態，如果處于停止狀態就發送，如果正在運動，就不發送，同時給用戶回傳一個提示。uj5u.com熱心網友回復：
電機是先運動的。只是在半路上遇到傳感器SB1，然后SB1被激發給了PLC一個信號，繼而PLC又把這個信號傳給C#。
uj5u.com熱心網友回復：
這個問題不應該靠C#解決，而是應該靠限位來解決。uj5u.com熱心網友回復：
是靠PLC來解決。
不過，C#也得知道。C#得持續地知道傳感器SB1的狀態，就是用C#去持續地監視PLC里M100.0的狀態
uj5u.com熱心網友回復：
還是業務邏輯設計得不合理，安全合理的設計應該是撞到限位開關直接停，連PLC都用不到，一切都是運動控制器在干活。C#更是不應該摻和進來。上位機軟體想知道電機狀態，可以啊，輪詢也好，按需檢測也好。
上位機想發送運動命令，可以啊，發前先取一下M100，電機處于運動狀態就告訴用戶現在電機在運動，等會重試，電機處于停止狀態就直接發送運動命令。
uj5u.com熱心網友回復：
不一定是遇到傳感器就停止，我說停止只是舉個例子；也有可能是遇到傳感器就反轉。實際情況有多種。傳感器的信號還是得接進PLC的。
uj5u.com熱心網友回復：
無非是帶不帶偏置，都一回事。做限位相關的功能，PLC只有在搜索零點的時候，或者到達限位以后有其它動作的時候才用得到。上位機更是絕對不應該用到。uj5u.com熱心網友回復：
如果只是單純監控信號，要么輪詢，要么用中斷（取決于控制器的SDK）。在任何場景里，都要把上位機軟體當成一種不可靠的物件去考慮。它會死機，會報錯，會例外退出，甚至壓根沒在運行。越是底層的控制需求，越是要用控制器或者PLC去處理。uj5u.com熱心網友回復：
你陷入一種誤區信號采集歸信號采集和語言無關
你也無須糾結什么while（ture）不while（ture）
本身信號傳輸就推拉兩類。下面的肯推給你，你無需折騰。只是標準的串口，tcp通訊
下面的不給推，非讓你自己拉。當然就是定時拉，你繞不過去。
哪怕你采用一個硬體采集卡，其實就像樓上說的一樣，那個還是輪詢+中斷
應該做什么就做什么，無需跟那個園子學糾結。
如果你實在要糾結什么我就是不要無限回圈，那也行把。
1.換C++寫驅動，直接下定時中斷
2.加掛硬體采集卡，讓采集卡直接硬體給你做采集（把你說糾結的回圈交給硬體去玩）
3.中間接opc，把你的采集交給opc去采集
uj5u.com熱心網友回復：
首先要說，.net 現在早就是“異步編程的經典”工具了，你可以撰寫異步且主動“死”回圈的代碼，例如public async void 開始監視SB1()不懂 async void 這個語法就需要學習、否則就無法跟上我們開發的節奏了。
{
while(stopFlag)
{
讀取狀態并處理();
await Task.Delay(150);
}
}
其次，從底層來說，良好的“監控”需要雙向設計通訊協議。也就是上位機發送一個或者幾個特定含義的召喚命令，然后下位機反饋訊息。如果你不設計合適的信令訊息，那么路邊攤是做不出工匠的瓷器活兒的。
uj5u.com熱心網友回復：
.net （包括 vb.net 等等，以及 Blazor Assembly在網頁上運行的 c# 程式）現在都是支持 .net 各種大型異步微任務（Task）編程的，可以輕松撰寫高性能的（準）實時異步演算法的系統。這個需要及早將知識升級換代。我們面試 c# 程式員都很少僅僅面試傳統的資料結構、演算法問題了，更多地看類似 Linq、Task、Actor設計模型等等知識的運用。而從通訊角度看，許多人的盲點更多。編程要“親自設計信令”，自己動手設計訊息的規范，并且親自撰寫決議代碼，除錯報文互動程序，測驗應用客戶端使用通訊介面之后的性能改善。自己養大的孩子才真的會重視起來通訊層設計得不好對應用的干擾。
uj5u.com熱心網友回復：
一般的 PLC 通訊，遵循某種比較好一點兒的工業協議，上位機首先發送一個“監控”指令，例如通知下位機傳送某些地址的資料，那么下位機就會在這些地址的數值發生改變時主動發送一條訊息給上位機。這就是雙向的協議。在基本的編程語法之外，這其實是個設計理念問題，說“架構”有點太“大”了，這類東西不用什么架構師，在控制方面做過設計的專業程式設計師即可。轉載請註明出處，本文鏈接：https://www.uj5u.com/net/258587.html
標籤：C#
上一篇：有用過移動作業站的嗎？感覺與普通筆記本相比有什么優勢？是必須買的嗎？
下一篇：c# 用IrisSkin4做換膚挺好的，但是在主視窗啟動執行緒就時不時報錯，說“物件當前正在其他地方使用”，請教大家該如何解決