Appendix 7 - Accessing the Point Id From the Read Request

Q. From the toByteArray method of my read request, how do I access the point ID? I can easily access the read parameters but not the point ID!

A. There is not necessarily a single point ID for the read request.

Discussion: Many protocols feature requests whose responses return the values for more than one data point. To accommodate polling in this fashion, devDriver combines (groups) all driver control points that have the equivalent Read Parameters into the same Read Request. The relationship between driver control points to a read request is potentially many-to-one. Because of this, a read request does not necessarily have just one pointId, it could have many pointIds.

In the event that many driver control points are automatically placed in the same read request, all of them will have the same Read Parameters (they all could have different pointIds). For this reason, the pointId is generally used from the parseReadValue method on the read response (as opposed to the read request). The philosophy is that the readParameters structure should have enough information to formulate the outgoing request. Then on the response side, the pointId should have any extra information (if there is any) that is required to index into the response and extract the data value for the particular data point.

Some protocols have a read request that retrieves many data values, but requires that each desired value be specifically requested. For example, in this scenario a request might state "Please Read Inputs 1, 2, 3, 4, 5, 6, 7". The response would then return the values that were requested (Inputs 1, 2, 3, 4, 5, 6, 7). In this scenario, you can get the array of point IDs that are assigned to the read request (see line item two just below). However, even in this scenario, it still might be better to add a property to the readParameters structure (perhaps an enumeration whose possible values would be inputs1_7, inputs8_15, etc.). Doing so would take maximum advantage of devDriver's ability to combine as many driver control points as possible into a single read request.

Final Answer:

To access the point ID for the read request, there are two options:

Move the particular property that you need to access from the pointId into the readParameters. This step is generally the suggested course of action because it takes maximum advantage of devDriver's ability to combine as many driver control points as possible into a single read request.
From your toByteArray method call getReadableSource(). This returns an array of IDdfReadable. These are the proxy extensions for all of the driver control points that share the same read parameters structure and therefore share the same read request. Then loop through the array of IDdfReadables, verify that each is an instance of your driver's proxy ext class (future support of virtual points anticipated), cast each to your driver's proxy ext class, call getPointId() upon each, cast the result to your driver's point id class, and directly access the point id. Please beware that this step might not allow devDriver to combine as many driver control points as possible into a single read request.

Note: Niagara will allow the user of the driver to add two identical control points to the database. This would be accomplished by choosing a row in the Discovered list of the point manager and simply adding it two or more times to the database. In this scenario, the devDriver framework will likewise group each of the identical database points into the same read request. This optimizes throughput on the field-bus by using one single read request to update each of the identical data points. Please keep this in mind while choosing option one or option two from above. If you choose option two but then always index into location zero of the readable source array (in a hard-coded manner) then please consider switching to use option one instead.