This section describes how to create a product based on an existing product, e.g. a new version or a similar product with a different number of channels.
Case 1: A KNX Manufacturer Tool project exists for the old product
In this case, start with a copy of the existing project. This has the following advantages:
·All developer-only properties (e.g. various InternalDescription properties) are available
·For ETS3 application programs: the original channel structure is available
To modify an application program:
·Be sure to change the application version and/or the application number first.
·You will be prompted if the internal shall be updated as required (Update IDs). Respond yes.
·Existing Hardware2Program and CatalogItem elements are still referencing the old application program and are thus not valid any more after this change. You will be asked whether or not these shall be deleted.
Case 2: Only a native knxprod file exists
If only a native ETS4/ETS5 product database (not converted from vd*) is present, a KNX Manufacturer Tool project can be created from this (see Open a Product Data file).
Except for missing developer-only properties, this is just as good as Case 1.
Note that the converter creates a very specific project structure with specific file names. Since the structure and names of files plays no rule in MT, you may move or rename the files freely. You may want to do this to avoid confusion e.g. because the file name of an application program file may not match a changed application program version, or the manufacturer ID is misleading after an OEM copy.
Case 3: Only a vd* file exists
If only a product database converted from vd* is present, a KNX Manufacturer Tool project can be created from this (see Open a Product Data file).
Case 3a: Target ETS4/ETS5
See Migrating an ETS3 product to a native ETS4/ETS5 product.
Case 3b: Target ETS3
Since the data in KNX MT is produced by the Converter, and thus is in ETS4/ETS5 format, targeting ETS3 requires an additional step for application programs: After changing the application version and/or application number, updating the internal IDs and handling existing Hardware2Program and CatalogItem items as described above, the application program has to be prepared for targeting ETS3. This can be done either by checking the corresponding check box in the "Application program ID Updated" dialog, or later by selecting "Prepare for targeting ETS3" from the context menu of the application program. This will perform the following actions:
oRe-set the "ConvertedFromEts3Data" flag used by ETS4/ETS5 to recognize converted application programs
oClear Name, Text and Access properties at all ParameterBlocks; the page texts and access rights are stored in the assigned Parameter[Ref] for ETS3 application programs.
Migrating an ETS3 product to a native ETS4/ETS5 product
Just changing the target to ETS4/ETS5 and setting MinEtsVersion to Ets40/Ets50 is neither correct not useful.
It is not correct, because ETS4/ETS5 handles ETS3 application programs in a special way both when displaying the parameter dialog and when creating the download image:
·Channels are not displayed
·Page information is retrieved from the parameters assigned to ParameterBlock elements, not from the ParameterBlocks themselves
·The DisplayOrder properties of ParameterRefs are evaluated
·When creating the download image, inactive parameters will not be filled with their default value, but rather with the value stored in the segment data.
It is not useful because such a direct migration would not exploit the possibilities of the new dynamic structure:
·Multiple ParameterRefRef/ComObjectRefRef elements can refer to the same ParameterRef/ComObjectRef
·Advanced conditions in When elements (e.g. "≥5")
·Choose elements referencing parameters in different branches of the Dynamic structure
·Assign and ParameterBlockRename elements
Migration to a native ETS4/ETS5 product is therefore no trivial task and is recommended only for product which will really benefit from the new dynamic structure, e.g. by cutting down the size of the application program data. A possible strategy for migration could be:
·for multi-channel devices, delete everything but the first channel (from the dynamic structure, but also from ParameterRef, ComObjectRef)
·Use the menu command "Remove ETS3 specific information" (Context menu) to fix up data that is not allowed in ETS4/ETS5:
oRemoves any page parameters, setting the page title directly in the ParameterBlock element. If the former page parameter is references in a choose element, it is transformed to an invisible ParameterRefRef.
oRemoves the DisplayOrder attribute from ParameterRef and EnumerationValue elements
·remove any duplicated branches in the dynamic structure by exploiting the advanced When conditions and the freedom of choice for the parameter referenced in the Choose element
·extensively test the first channel
·duplicate the channel as described in Multi-channel application programs.
Consider using the "Replaces Versions" function (see ApplicationProgram and Update Application Program) to help ETS users if they want to update existing project data.