Creating a New DQMH Event

The different events

A DQMH Event can be either a request or a broadcast.

A request is code that fires an event that the DQMH Module Main.vi has to act on.
A broadcast is code that fires an event that informs other VIs that are registered to listen that the DQMH Module Main.vi has done something.
There are also synchronous events of the type request and wait for reply. These events are fired when the DQMH Module Main.vi needs to return a reply to the VI that called the request and this calling VI must wait until it gets that reply (or the request times out).

Create a new event:

Videos demonstrating the following steps and other examples are available at: bit.ly/DelacorQMH

Go to Tools>DQMH Consortium>DQMH>Event>Create New DQMH Event….
Two windows will open: the Create New DQMH Event window and the Arguments Window.

If you select to create a Request and Wait for Reply, an additional Arguments Window will open.

1	In the Create New DQMH Event window select the DQMH module for which you wish to create a new event. This drop down menu will only list valid DQMH modules found within the project.
2	In the Create New DQMH Event window, specify the type of event you wish to create. A description of each event type appears next to the drop down selection: Request: An event generated by a caller that the module is registered to receive. Typically a request event is a request for the module to ``Do something''. For a request event, check the box if you want the tool to add a button to the API Tester to fire this event (this will reduce the number of things you need to do when the tool creates the request event and its associated code). Broadcast: An event generated by the module to let any external code that is registered to receive the event know that ``Something happened''. Typically a broadcast event is generated after the module acts on a request. For broadcast events, you are given the option to use the same argument as an existing request. An example would be a request to confirm if current calibration values are up to date. The request argument could be the current calibration values, and the request argument could be the up to date calibration values. Request and Wait for Reply: A request event where the event generator waits for the module to process the request and return the request processing results. This provides synchronous request and reply functionality. An additional DQMH Arguments Window will appear for the Reply Payload arguments. Round Trip: A request and wait for reply event and a broadcast event where the Reply Payload and the Broadcast Argument are the sametypedef. The request and wait for reply event has an input to determine whether the code should wait or not for the reply. In the case where the code doesn’t wait for the reply, these events are asynchronous but may be logically related (i.e., Do Something and Did Something). In the case where the code does wait for the reply, the broadcast provides the opportunity of notifying other VIs, registered to listen to the broadcast, when another VI has called the request and is waiting for a reply. This is particularly useful in TestStand projects where the TestStand step needs to wait for the reply and we might want to use the API Tester as a sniffer and still see the reply reported there via the broadcast event.
3	Specify the name of the new event (in the case of the Round Trip option, specify the name for the request and the name for the broadcast).
4	Add controls to the Arguments window. These values will be the arguments sent along with the event when it fires. Use a descriptive label for each control. There is no need to wrap the arguments with a cluster in that window. The utility will take the controls in the Arguments window and add them to an Arguments typedef cluster. If you wish to receive all the arguments as a single cluster in the event loop, when the event fires, you may choose to wrap the arguments in a cluster. Examples include an x,y point, or a left, right, top, bottom values for a rectangle etc. For Request and Wait for Reply events, a notifier reference does not need to be added in the Arguments window. The Create New DQMH Event utility will create the notifier and its typedef cluster payload automatically. If the event is being created for a cloneable module, there is no need to add the Module ID control. The Create New DQMH Event utility will add the Module ID control to the Arguments typedef cluster automatically. Existing typedefs can be added to the Arguments window. If a new typedef is created in the process of adding controls to the Arguments window, you will be prompted to save the typedef before the event can be created. At least one control has to be added to the Arguments window. This will make it easier to modify the code if the developer changes his mind and an argument is needed in the future. At that point a typedef argument cluster will be available for the developer to add other arguments.
5	(Optional but heavily encouraged) Enter a description for the event. This description will be included as the VI documentation for the VIs that this tool created to fire the event created.
6	Click OK to create the new event(s). The new event VI(s) will be selected in the project explorer window after creation is complete.

TheDQMH Module Main.vi and Tester VI might be broken.

The developer has to complete several actions to complete the creation of this code, all of which are identified with #CodeNeeded bookmarks that can be explored with the Bookmark Manager window.

DQMH 3.0 adds automatic wiring of event structure frames when used in LabVIEW 2016 or later.

The developer needs to complete the following actions:
- In the case of a new Request:
  - In the Tester VI:
    
    Add a new front panel control to test the new request event. Note that DQMH 4.2 adds automatic wiring of a test button on the API Tester if this option was selected at event creation time.
    
    Open the block diagram, which should be showing the newly added event frame with the new request VI inside. Right-click on the event structure, select Edit Events Handled by This Case, and select the control added in the previous step. Note that DQMH 4.2 will take care of this step automatically if the developer selected this option at event creation time.
    
    By default, all the inputs of the request VI are required. Wire appropriate inputs to the request VI.
    
    The Tester VI should no longer be broken (assuming it was not broken before the new event was added).
  - In the DQMH Module Main.vi:
    
    Open the block diagram, which should be showing the newly added event frame in the EHL and the newly added case frame in the MHL.
    
    Right-click the event structure, select Edit Events Handled by This Case, and select the newly created request that should be listed under Dynamic>><Module Name> Request Events.
    
    Wire the event data (<arguments label(s)>) to the Bundle function in the event frame.
    
    Add necessary code to the <request name> frame in the MHL case structure.
- In the case of a new Broadcast:
  - In the Tester VI:
    
    Open the block diagram, which should be showing the newly added event frame with the #CodeNeeded bookmark. Right-click the event structure, select Edit Events Handled by This Case, and select the newly created broadcast that should be listed under Dynamic>><Module Name> Broadcast Events.
    
    Add code to process the event data sent by the broadcast event.
    
    The Tester VI should no longer be broken (assuming it was not broken before the new event was added).
  - In the DQMH Module Main.vi:
    
    Open the block diagram, which should have the newly created broadcast VI on the left side with a #CodeNeeded bookmark.
    
    Move that VI wherever the newly created broadcast event needs to be called.
- In the case of a new Request and Wait for Reply:
  - In the Tester VI:
    
    Add a new front panel control to test the new request event.
    
    Open the block diagram, which should be showing the newly added event frame with the new request VI inside. Right-click the event structure, select Edit Events Handled by This Case, and select the control added in the previous step.
    
    By default, all the inputs of the request VI are required. Wire appropriate inputs to the request VI.
    
    Process the reply payload output from the new request VI.
    
    If the payload argument needs to be changed, open the new request VI and right-click the Reply Payload indicator to open its typedef and edit it accordingly.
    
    The Tester VI should no longer be broken (assuming it was not broken before the new event was added).
  - In the DQMH Module Main.vi:
    
    Open the block diagram, which should be showing the newly added event frame in the EHL and the newly added case frame in the MHL.
    
    Right-click the event structure, select Edit Events Handled by This Case, and select the newly created request that should be listed under Dynamic>><Module Name> Request Events.
    
    Wire the event data (<arguments label(s)>) to the Bundle function in the event frame. Take special care to wire the Wait Notifier event node output to the Bundle function that the utility added.
    
    Add necessary code to the <request name> frame in the MHL case structure.
    
    Wire the proper reply to the Send Notification function.

DQMH versions before 4.1, created the Round Trip differently, in those versions the Round trip was a combination of a request and a broadcast where both events shared the same argument typedef. Based on feedback from the DQMH community and DQMH development team’s own experience, we decided to change the round trip to be now the combination of a request and wait for reply and a broadcast.