Chapter 10 - Create a Read Parameters Structure For Your Driver

In the previous chapter, you created a read request. We asked you to construct a byte array and return it from your read request's toByteArray method. We asked you to assume that a read parameters structure contained any information, other than information about the device itself, that you would need in order to construct a request message from your driver's protocol -- that is, a request message that asks a field-device for one or more data values.

This chapter will guide you through the creation of the read parameters structure.

While following the examples in this chapter, please replace the text jarFileName, yourDriver and yourCompany as previously described in the Preparation section):

Review your read request's toByteArray method.

Make a Java class that extends BDdfReadParams. Name it BYourDriverReadParams. Create this in a package named com.yourCompany.yourDriver.identify. Also add an empty slotomatic comment immediately after the opening squiggly brace for the class declaration.

To do this, create a text file named BYourDriverReadParams.java in the jarFileName/src/com/yourCompany/yourDriver/identify folder. Inside the text file, start with the following text:

package com.yourCompany.yourDriver.identify;

import javax.baja.sys.*;

import com.tridium.ddf.identify.*;

import com.yourCompany.yourDriver.comm.req.*;

public class BYourDriverReadParams
  extends BDdfReadParams
{
  /*-
  class BYourDriverReadParams
  {
  }
  -*/
}

Add a properties section to the slotomatic header and declare properties for any values that you needed in order to make the toByteArray method (function) in your read request.

In our hypothetical example, we required two string properties. In the example toByteArray method, we accessed these by calling the getTypeString and getDirection methods. We designed the code for the toByteArray method (function) like this because we planned that when creating the read parameters structure, we would add these properties to it. We understood that by naming these two properties typeString and direction that the Niagara AX slotomatic utility would automatically generate a getTypeString method and a getDirection method.

Please make the slotomatic statement on your read parameters structure look something like this:

  /*-
  class BYourDriverReadParams
  {
    properties
    {
      typeString : String
        -- This property has nothing to with the dev
        -- driver framework itself. Instead, we need
        -- to construct the toByteArray method of the
        -- driver's read request in following the
        -- driver's protocol to read data values.
        default{["analog"]}
        slotfacets{[MGR_INCLUDE]}

      direction : String
        -- This property has nothing to with the dev
        -- driver framework itself. Instead, we need
        -- to construct the toByteArray method of the
        -- driver's read request in following the
        -- driver's protocol to read data values.
        default{["outputs"]}
        slotfacets{[MGR_INCLUDE]}
    }
  }
  -*/

NOTE: Providing the slotfacet of MGR_INCLUDE on each of these properties will cause them to automatically appear in your point manager for your driver.

Override the getReadRequestType method and return the TYPE of your driver's read request.
Please note that we have not yet asked you to run the slotomatic utility today, therefore, the java file for your read request class file might not yet have a TYPE constant (unless you ran the slotomatic utility on your own). The Niagara AX slotomatic utility will automatically add the TYPE constant to that file, and the java files for the other classes that you will be creating today. Do not worry, we will ask you to run the slotomatic utility and the build utility at the end of the next chapter.
Add the following code to BYourDriverReadParams.java:
public Type getReadRequestType(){return BYourDriverReadRequest.TYPE;}