1 / 21

Changing the CS Event Mechanism

Changing the CS Event Mechanism. Definition of "Event" Concepts of the old event mechanism Implementation Status Misconceptions within the old implementation Concepts of the new event mechanism Implementation Status. Why events?. separation of function in self-contained entity

kobe
Download Presentation

Changing the CS Event Mechanism

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Changing the CS Event Mechanism Definition of "Event" Concepts of the old event mechanism Implementation Status Misconceptions within the old implementation Concepts of the new event mechanism Implementation Status

  2. Why events? • separation of function in self-contained entity • needed to pass information (like commands) from one entity to another • events can be buffered (like e-mail) or unbuffered (like phone)

  3. an entity waits for the next event, no polling! timeout handling is an important issue Event basics command pattern: "many-to-one" observer pattern: "one-to-many" client client client publisher data command subscriber subscriber subscriber receiver example: radio, television example: typical human communication

  4. based purely on the command pattern no intrinsic bottle neck one object ("caller") sends a command to another object ("callee") Central PC DSC Interface DSC Engine Sequencer Data Acquisition Timing AFG High Voltage DataAcq. Instr. Driver Timing Instr. Driver AFG Instr. Driver HV Instr. Driver Front-end PC 1 Front-end PC n Event Hardware Software (Proc) Software (Lib) Exp. Specific General Part Buy! OPC CS: old event mechanism Start SetVoltage SetFrequency SetDelay

  5. Caller Callee localhost Simple Call Caller Client_node2 Server_node1 Callee node1 node2 LabVIEW message queue TCP/IP • thread of caller continues execution • no feedback from callee (except: “callee does not exist”) • format of callee: "object@node"

  6. DSC (Interface + Engine): Central event manager for trending data Central PC DSC Interface DSC Engine RegisterTo "A" Sequencer SetValue "B" SetValue "A" Update "A" Data Acquisition Timing AFG High Voltage DataAcq. Instr. Driver Timing Instr. Driver AFG Instr. Driver HV Instr. Driver Front-end PC 1 Front-end PC n Event Hardware Software (Proc) Software (Lib) Exp. Specific General Part Buy! DSC Engine and DSCTrend events

  7. callee format "object@nodename" limits to one executable per node binds an object to one specific node: the caller must know, on which node the object was created (like a fixed phone number) (caller needs to know type of event (message queue or notifier)) two identical objects could exist on two (or more) nodes LabVIEW TCP/IP implementation poor performance determining the local "nodename" is extremely ambiguous DSC (Interface + engine) misused to implement observer pattern by using the command pattern coupling of SCADA functionality and on-line trending strong limitation on number of process variables TCP Client/Server setting up and maintaining connections causes significant overhead poor performance due to multiple copying of data first call gets lost  implementation sometimes difficult, bad scaling with number of process variables Deficiencies of old event mechanism

  8. callee format "object" many executables per node caller is ignorant to node of callee (like a mobile phone) (caller is ignorant of type of call (message queue or notifier)) one object may exist only once within a distributed control system no further usage of LabVIEW TCP/IP implementation improved performance use command pattern and observer pattern SCADA backend is a real back end, and no central event manager built-in on-line trending TCP Client/Server setting up and maintaining connections must be encapsulated avoid unnecessary copying of data lossless transfer of data  simpler implementation of user code, better scaling to large systems Demands to new event mechanism

  9. DIM (Distributed Information Management) is a light weight package for information publishing, data transfer and inter-process communication, http://www.cern.ch/dim/. Originally, DIM has been developed at Delphi/CERN. Today, DIM is one of the backbones for many experiments at CERN, including all four LHC experiments. Maintained at CERN and available via GPL. Thanks to C. Gaspar et al. The solution: DIM knows node of client and server arranges connections command pattern observer pattern

  10. fully event driven, using call back functions with DIM uses "native" DIM libraries (no re-write) client and server functionality for commands and services New (!) LabVIEW-DIM interface my application LabVIEW runtime engine, NI LVEvent dll/so, GSI DIM Wrapper dll/so, GSI DIM dll/so, C. Gaspar, CERN

  11. Step I (example for message queue) • compile this VI into LVEvent dll/so • this makes the LV message queue available in a C/C++ environment

  12. void serv_receivedCB(callBackID,address,size) int *callBackID; //identifies a callback char *address; //address where the data is available int *size; //length of available data { LVBoolean timedOut; //dummy //check range if ((*callBackID < 0) || (*callBackID >= MAXSERVICES)) return; //put data into message queue if (callBacks[*callBackID].callBackID == *callBackID ) //verify call back identifier { if (callBacks[*callBackID].refNumType == 0) LVEvent_EnqueueElement(&(callBacks[*callBackID].refNum), 1, address, *size, &timedOut); if (callBacks[*callBackID].refNumType == 1) LVEvent_SendNotifier(&(callBacks[*callBackID].refNum), address, *size); //notifier } } //serv_receivedCB provide call back function, that inserts new data into message queue compile into the DimWrapper.dll/so Step II

  13. DIMWRAPPER_API int dicInfoService(char *serviceName, LVRefNum *refNum, int refNumType, int serviceType, int timeout) { ........... //determine callback ID callBacks[callBackID].callBackID = callBackID; callBacks[callBackID].refNum = *refNum; callBacks[callBackID].refNumType = refNumType; callBacks[callBackID].serviceId = dic_info_service(serviceName, serviceType, timeout, 0, 0, serv_receivedCB, callBackID, noLink, strlen(noLink)); return callBackID; } //dicInfoService provide function, that registers to DIM via my callback function compile into the DimWrapper.dll/so Step III

  14. Example: Client with Queue

  15. DSC (Interface + Engine): Central event manager for trending data Event DSCTrend with old event mechanism Central PC DSC Interface DSC Engine Sequencer RegisterTo "B" RegisterTo "A" Update "A" Update "B" SetValue "B" SetValue "A" Data Acquisition Timing AFG High Voltage DataAcq. Instr. Driver Timing Instr. Driver AFG Instr. Driver HV Instr. Driver Front-end PC 1 Front-end PC n Hardware Software (Proc) Software (Lib) Exp. Specific General Part Buy!

  16. DSC (Interface + Engine): Central event manager for trending data Event DSCTrend with new event mechanism Central PC Sequencer Update "B" RegisterTo "A" Update "A" RegisterTo "B" Data Acquisition Timing AFG High Voltage DataAcq. Instr. Driver Timing Instr. Driver AFG Instr. Driver HV Instr. Driver Front-end PC 1 Front-end PC n Hardware Software (Proc) Software (Lib) Exp. Specific General Part Buy!

  17. Simple Call old: or(!) Caller Client_node2 Server_node1 Callee node1 node2 LabVIEW message queue or notifier LabVIEW TCP/IP DIM TCP/IP new: DimWrapper Caller Callee node1 node2

  18. Improving "separation of functions" old new

  19. Event rates with DIM based CS

  20. Throughput with DIM based CS

  21. Summary new old  Future CS versions based on DIM?

More Related