程序结构设计祥解.ppt

* This gives you more control on how your application is timed, and gives the user more control over your application. Counterexample: Data-acquisition and data-logging in the same loop. It would be difficult to increase the rate of DAQ without increasing rate of data logging. If they are separate of each other then this is easier to do The standard Master/Slave design pattern approach for this application would be to put the acquisition processes into two separate loops (slave loops), both driven by a master loop that polls the user interface (UI) controls to see if the parameters have been changed. To communicate with the slave loops, the master loop writes to local variables. This will ensure that each acquisition process will not affect the other, and that any delays caused by the user interface (for example, bringing up a dialog) will not delay any iteration of the acquisition processes. Define data dependency: Loop B is dependent upon Loop A if any of Loop B inputs require values from loop A outputs * Now that we’ve discussed the concept of having multiple loops for separate processes, lets talk about how we can bridge those loops in order to communicate without creating any data-dependency. There are a number of different mechanisms we can use depending upon the communication required. For synchronization and timing an occurance or rendezous are helpful. We’re going to focus on the use of queues Notifier Operations Functions Use the Notifier Operations functions to suspend the execution of a block diagram until you receive data from another section of the block diagram or from another VI running in the same application instance. Occurrences Functions Use the Occurrences functions to control separate, synchronous activities. Queue Operations Functions Use the Queue Operations functions to create a queue for communicating data between sections of a block diagram or from another VI. Rendezvous VIs Use the Rendezvous VIs to synchronize two or more