Creating a New DQMH Event

The different events

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

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 DQMH Arguments Window.

Image
If you create a Request and Wait for Reply event, the DQMH Reply Payload Window will also open.
Image
1 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 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".

    • 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).

    • Specify whether you want the scripted EHL code for this new request to use the standard DQMH Enqueue Message VI (default behavior) or a custom Enqueue Message VI that you specify by path.

    • Configure the Request Scoping of the event to be Public or Private. The default selection is "Public", which is the most common case.

    • For DQMH Main VIs with multiple event loops, specify the Consuming Event Loop that will be registered for the new event.

  • 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.

    • Specify whether or not you want the new broadcast event to have its own argument typedef (default behavior), or to use the same argument as an existing request. An example use case for selecting the argument of an existing request would be a request to confirm if current calibration values are up-to-date. The request argument could be the expected calibration values, and the value returned by the broadcast would be the actual calibration values.

  • Request and Wait for Reply: A request event where the code that calls the event waits for the module to process the request and return results. This provides synchronous event functionality. As described above, an additional DQMH Reply Payload Window will appear for the Reply Payload arguments.

    • Follow the instructions in the Request section above to select options for a tester button, a custom Enqueue Message VI, and the consuming event loop.

    • Specify whether or not the Wait for Reply will timeout based on the module-wide timeout (default behavior), or a custom timeout value that you provide.

  • Round Trip: This event type is a combination of two events: a Request and Wait for Reply event and a broadcast event where the Reply Payload and the Broadcast Argument are the same typedef. 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 does not 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 broadcast listeners 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.

    • Follow the instructions in the Request section above to select options for a tester button, a custom Enqueue Message VI, and the consuming event loop.

    • Follow the instructions in the Request and Wait for Reply section above to select options for the reply timeout value.
3 Specify the name of the new event. For Round Trip events, you must specify names for both event components.
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. 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 XY point, rectangular coordinates, 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 even] is being created for a cloneable module, there is no need to add the Module ID control. The Module ID will be included in 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.

  • A typedef cluster will be created that wraps the controls dropped in the Arguments window. If no controls are added, the typedef cluster will contain a placeholder Boolean control that can either be ignored, or replaced with other argument parameters at a later time.
5 Enter a description for the event. This description will be included as the VI documentation for the new event VI(s).
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.

The DQMH 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.

  1. The developer needs to complete the following actions:

    • In the case of a new Request:

      • In the Tester VI:

        1. By default, all the inputs of the request VI are required. Wire appropriate inputs to the request VI.

        2. 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:

        1. Add necessary code to the <request name> frame in the MHL case structure.

    • In the case of a new Broadcast:

      • In the Tester VI:

        1. Add code to process the event data sent by the broadcast event.

        2. 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:

        1. Open the block diagram, which should have the newly created broadcast VI on the left side with a #CodeNeeded bookmark.

        2. 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:

        1. By default, all the inputs of the request VI are required. Wire appropriate inputs to the request VI.

        2. Process the reply payload output from the new request VI.

        3. 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.

        4. 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:

        1. Add necessary code to the <request name> frame in the MHL case structure.

        2. Wire the proper reply to the Send Notification function.