M&M FDT 1.2.1 Online Specification
 6.16.1 Comparison Without User Interface


Interfaces and Methods   -   Schemas   -   FDT Specification   -   Quicklinks   -   Abbreviations

Up to FDT Specification

6.1 DTM Peer To Peer Communication
6.1.1 Establish a Connection between DTM and Device
6.1.2 Asynchronous Connect
6.1.3 Asynchronous Disconnect
6.1.4 Asynchronous Transaction
6.2 Nested Communication
6.2.1 Generate Systemtopology
6.2.2 Establish a Connection between DTM and Device
6.2.3 Asynchronous Transaction
6.3 Topology Scan
6.3.1 Scan Network
6.3.2 Cancel Topology Scan
6.3.3 Provisional Scan Result Notifications
6.3.4 Scan for Communication Hardware
6.3.5 Manufacturer specific Device Identification
6.4 Registration of Protocol Specific FDT Schemas
6.5 Configuration of a Fieldbus Master
6.6 Starting and Releasing Applications
6.7 Channel Access
6.8 DCS Channel Assignment
6.9 Printing of DTM Specific Documents
6.10 Printing of Frame Application Specific Documents
6.11 Propagation of Changes
6.12 Locking
6.12.1 Locking for Non Synchronized DTMs
6.12.2 Locking for Synchronized DTMs
6.13 Instantiation and Release
6.13.1 Instantiation of a New DTM
6.13.2 Instantiation of an Existing DTM
6.13.3 Instantiation of a DTM User Interface
6.13.4 Release of a DTM User Interface
6.14 Persistent Storage of a DTM
6.14.1 State machine of instance data
6.14.1.1 Modifications
6.14.1.2 Persistence
6.14.2 Saving Instance Data of a DTM
6.14.3 Reload of a DTM Object for Another Instance
6.14.4 Copy and Versioning of a DTM Instance
6.15 Audit Trail
6.16 Comparison of Two Instance Data Sets
6.16.1 Comparison Without User Interface
6.16.2 Comparison With User Interface
6.17 Failsafe Data Access
6.18 Set or Modify Device Address With User Interface
6.19 Sets or Modifies Known Device Addresses Without User Interface
6.20 Display or Modify All Child Device Addresses With User Interface
6.21 Device Initiated Data Transfer
6.22 Starting and Releasing DTM User Interface in Modal Dialog
6.23 Parent Component Handling Redundant Slave
6.24 Initialization of a Channel ActiveX Control
6.24.1 Supports IFdtChannelActiveXControl2
6.24.2 Does Not Support IFdtChannelActiveXControl2
6.25 DTM Upgrade
6.25.1 Saving Data from a DTM to be Upgraded
6.25.2 Loading Data in the Replacement DTM
6.26 Usage of IDtmSingleDeviceDataAccess::ReadRequest / Write Request
6.27 Instantiation of DTM and BTM

6.16.1 Comparison Without User Interface

The sequence chart for the comparison of two instance data sets is as follows:
Used methods:
IDtmDiagnosis::InitCompare()
IDtmDiagnosis::Compare()
IFdtTopology::GetDtmForSystemTag()
IFdtTopology::ReleaseDtmForSystemTag()

Comparing two device type instances is one of the worst-described and worst-designed functions of the FDT technology for two reasons:
  • The comparison process is a synchronous action. The Compare() method needs to return a result immediately. Due to that, the DTM needs to implement a message pump. This is some kind of critical. An actually, if we have it as a synchronous operation, one method would have been sufficient. Why does FDT need the InitCompare() and ReleaseCompare() method? GetDtmForSystemTag() and ReleaseDtmForSystemTag() could also be called in the Compare() method itself.
  • It is not defined in which environment the second copy should be started. There are three possibilities:
    a) the copy is started without any topology around, which means that the copy cannot call GetChildNodes() or GetParentNodes().
    b) the copy is started with the same environment like the original. That means that the original DTM and the copy get the same system tags when calling GetParentNodes() or GetChildNodes()
    c) the copy is started in a copied environment. That means, it can call GetParentNodes(), but will get a copied parent instead of the original parent.
The correct way for this function would have been a method Compare() and a callback OnCompareFinished(). This would provide a real asynchronous operation, without the need for a message pump. In addition, the number of methods would be reduced in that case. Of course, the environment would still be needed to be defined. I would suggest that comparison must work without parent or child DTMs. The reason for this is, that the compared DTM should not include information in the comparison of other DTMs. If other DTMs are interesting to be compared, the frame application can call Compare() on those instances as well.
The reason for three methods seems to be the Comparison with user interface. But even in this situation, the type could have been modeled as XML and passed as argument for Compare() so that the DTM needs to open the user interface.
Another question is, why a copy of the DTM needs to be started for comparison anyway. From my point of view, the DTM could perform a comparison based on a persistence stream or property bag. The DTM is capable of loading the stream anyway.
This would also clarify the question of environment for the copied DTM.

© by M&M Software GmbH, parts of this website taken from FDT Interface Specification Version 1.2.1, © by FDT Group, AISBL.
This website is published for support of M&M products as granted in license conditions, chapter 2.1.
Last updated 2015-02-05 15:17
Email: FDT Technical Support Line.