MVME297-256模擬量輸入模塊
?組中的項目可以是活動(dòng)的或非活動(dòng)的。?組可以是活動(dòng)的或非活動(dòng)的。對于每個(gè)活動(dòng)組，DriveOPC中都有一個(gè)循環(huán)運行的線(xiàn)程。線(xiàn)程從設備讀取活動(dòng)項值，并在DriveWindow中調用所謂的通知接收器。DriveWindow內的所有在線(xiàn)活動(dòng)都使用此回調機制。?通常，當從設備讀取或寫(xiě)入值時(shí)，它也會(huì )緩存在DriveOPC中。?DriveWindow還可以直接讀取和寫(xiě)入值，而無(wú)需回調。每個(gè)讀/寫(xiě)操作可以包含多個(gè)項目。?DriveOPC緩存中值的初始質(zhì)量不好。DriveWindow不會(huì )自動(dòng)從設備中讀取某些項目（如數據記錄器通道緩沖區），并且在用戶(hù)請求更新之前，它們的質(zhì)量一直很差。高級信息驅動(dòng)窗口2 10-21如果使用本地服務(wù)器（EXE）版本，為了簡(jiǎn)單起見(jiàn)，這里沒(méi)有顯示其他線(xiàn)程。需要它們，因為DriveWindow和DriveOPC運行的是獨立的進(jìn)程，因此具有獨立的地址空間。然而，操作系統負責線(xiàn)程同步。當工作線(xiàn)程為客戶(hù)機線(xiàn)程執行作業(yè)時(shí)，客戶(hù)機線(xiàn)程總是在等待，因此當我們通過(guò)說(shuō)客戶(hù)機線(xiàn)程完成作業(yè)來(lái)簡(jiǎn)化時(shí)，我們不會(huì )失去任何重要的東西。一般的數據流結構如下：當一個(gè)線(xiàn)程（無(wú)論是內部DriveOPC線(xiàn)程還是DriveWindow線(xiàn)程）訪(fǎng)問(wèn)設備或DriveOPC內的內部數據結構時(shí)，訪(fǎng)問(wèn)由一個(gè)鎖同步，一次只允許一個(gè)線(xiàn)程處理數據。這意味著(zhù)，例如，一個(gè)擁有大量活動(dòng)項的組可以長(cháng)時(shí)間阻止所有其他訪(fǎng)問(wèn)，因為所有項都是在釋放鎖之前處理的。7.1.1屏幕刷新在這種情況下，用戶(hù)沒(méi)有直接請求更改屏幕上的值，但由于其他原因（例如，恢復最小化的DriveWindow），需要重新繪制屏幕。這些值從DriveWindow內部緩存中提取。該操作在DriveWindow內部完成。高級信息10-22 DriveWindow 2 7.1.2選擇更改在這種情況下，用戶(hù)更改瀏覽樹(shù)窗格中的選擇，并使用DriveOPC緩存的值重建項目集窗格。將數據記錄器顯示窗格中的選擇更改為已上載的數據記錄器的工作方式相同。該操作由DriveWindow線(xiàn)程使用非活動(dòng)項完成。7.1.3更新在這種情況下，用戶(hù)請求DriveWindow更新所選項目或上載數據記錄器，數據將從設備中提取并緩存。
? Items within a group can be active or inactive. ? A group can be active or inactive. For each active group, there is a cyclically running thread within DriveOPC. The thread reads the active item values from a device and calls a so called advise sink within DriveWindow. This call-back mechanism is used by all on-line activities within DriveWindow. ? Always, when a value is read from or written to a device, it is also cached within DriveOPC. ? DriveWindow also reads and writes values directly without the call-back. Each read/write operation can contain several items. ? The initial quality of values in the DriveOPC cache is bad. Some items (such as datalogger channel buffers) are not automatically read from a device by DriveWindow, and their quality stays bad, until the user requests updating of them. Advanced Information DriveWindow 2 10-21 In case the local server (EXE) version is used, there are additional threads not shown here for simplicity. They are needed because DriveWindow and DriveOPC are running is separate processes and thus have separate address spaces. The operating system, however, takes care of thread synchronisation. A client thread always waits while the working thread is executing a job for it, so we do not lose anything important when we simplify by saying that the client thread does the job. The general data flow structure is as follows: When a thread, whether an internal DriveOPC thread or a DriveWindow thread accesses a device or the internal data structures within DriveOPC, access is synchronised by a lock, which allows only one thread at a time to handle data. This means that a group having huge amount of active items, for example, can block all other access for a long time, because all the items are handled before the lock is released. 7.1.1 Screen Refresh In this case there no direct request from the user to change the values on the screen, but the screen needs to be redrawn for other reasons (restoring a minimized DriveWindow, for example). The values are drawn from the DriveWindow internal cache. The operation is done internally in DriveWindow. Advanced Information 10-22 DriveWindow 2 7.1.2 Selection Change In this case the user changes selection in the browse tree pane, and the item sets pane is reconstructed by using the values cached by DriveOPC. Changing selection in the datalogger display pane to an already uploaded datalogger works the same way. The operation is done by a DriveWindow thread using inactive items. 7.1.3 Update In this case the user requests DriveWindow to update the selected items or upload a datalogger, and the data is fetched from the device and cached.
