1.概述

　　隊列是來自數(shù)據(jù)結(jié)構(gòu)的一個概念，即數(shù)據(jù)的處理是按照先進先出(FIFO)原則執(zhí)行，在PLC的控制程序中有時也會用這種方法。

　　在一條生產(chǎn)線上的顆粒狀物料輸送設(shè)備中，有四路物料輸送管線，但抽取物料的羅茨泵只有一臺，因此在任意時刻只能有一條物料輸送管線工作，如果在這條管線工作時，其它物料管線有工作請求，只能排隊等待，在有等待狀況發(fā)生時的PLC程序的控制，是一個典型的隊列應用。

　　2 在Twido系列PLC中的實現(xiàn)方法

　　在Twido PLC中有現(xiàn)成的寄存器功能塊可以配置成隊列(FIFO)工作方式，最初也正是用這種方式編寫的PLC的控制程序，程序的幾處關(guān)鍵請看下面幾個程序段圖。

　　在程序調(diào)試階段，設(shè)備工作一切正常。但設(shè)備在實際運行中，總是會在1~3天內(nèi)發(fā)生1到2個物料輸送管線的請求不被執(zhí)行而始終處于等待狀態(tài)，只有斷電后重新啟動設(shè)備才能恢復正常工作。隨后又仔細分析了Twido PLC的寄存器(隊列模式)功能塊，發(fā)現(xiàn)使用它時必須保證四路物料輸送管線的請求在任意時刻不能同時有兩個請求發(fā)生，否則就會出現(xiàn)上面的問題，而實際工作中，兩個或兩個以上的請求同時(PLC的一個掃描周期，大約在10ms之內(nèi))發(fā)生的機率確實存在，正是這種不定期發(fā)生的同時出現(xiàn)的請求，使設(shè)備不定期地出現(xiàn)物料輸送管線的不正常工作。

　　找到原因后，在改寫PLC程序時發(fā)現(xiàn)，如果加上處理同時發(fā)生的幾個請求的程序，使得使用Twido所提供的寄存器(隊列模式)功能塊的程序可能會更加復雜，于是決定不使用這個功能，用常規(guī)編程來完成控制要求。

　　在程序需要重點考慮的就是這種多路物料輸送管線同時發(fā)生請求的情況。在程序中將每一個請求用自鎖回路保持住，然后將鎖定的信號驅(qū)動一個定時器，對請求的執(zhí)行是通過比較幾個定時器的當前值大小來決定那一路物料輸送管線動作。

　　在程序中編寫下面四個類似的程序段：

　　實現(xiàn)請求的判斷：

　　請求處理：

　　在請求處理程序段中已經(jīng)包含如果有同時發(fā)生的請求時，按照1->2->3->4的默認動作順序來決定優(yōu)先順序。

　　在使用改進后隊列處理程序后，該設(shè)備運行約兩年，一直工作正常，再沒出現(xiàn)過某路物料輸送管線的請求不被執(zhí)行的情況。

　　在這個案例中，說明有些情況下，使用PLC所提供的功能并不一定是最佳的解決方式，此時，不妨考慮一下?lián)Q一個實現(xiàn)思路的可能性。