Page tree
TopicFunct. BlockFunctionopt./mand.recomm.V4.1 chapt.V4.1 pageV4.1 ref.TaskNoteGSDMLImplementationimpl. Scheduleimpl. StatusTest StatusTest Scripts
1.0Parameter Channel (BMP)Block-No. 1mandatory
1.1BMP transport protocolmandatoryyes6.2.3.5 and 8.6.267 to 68 and 267 to 268fig. 24Implementation of the BMP transport protocol for the transport of the BMP request and response blocks.check most recent errata list, use "fault_code_definition.pdf".Define MAP submodule for parameter access according to the selected device model.yesstep 1a
1.2BMP request/response prot.mandatoryyes6.2.3.359 to 66tab. 24, tab. 25Implementation of the interpretation of the BMP request blocks and generation of the BMP response blocks.check most recent errata list.yesstep 1b
1.3BMP-Local access at 0xB02E IOARmandatoryyesMapping of the BMP service to data record 0xB02E of the dedicated MAP and other submodules for the IOAR.BMP access point at the MAP submodule ist mandatory. BMP access point at telegram submodules is optional. BMP access point at Profisafe submodule is recommended.yesstep 1d
1.4BMP-Global access at 0xB02F IOARoptionalnoMapping of the BMP service to data record 0xB02F of the dedicated MAP and other submodules for the IOAR.for compatibility to older version, not recommended for new development.nostep d
1.5BMP-Local access at 0xB02E device accessmandatoryyes8.4.3262Mapping of the BMP service to data record 0xB02E of the dedicated MAP and other submodules for the Device Access.BMP access point at the MAP submodule ist mandatory. BMP access point at telegram submodules is optional. BMP access point at Profisafe submodule is recommended.yesstep 1c
1.6BMP-Global access at 0xB02F device accessoptionalnoMapping of the BMP service to data record 0xB02F of the dedicated MAP and other submodules for Device Access.for compatibility to older version, not recommended for new development.nostep1c
1.7parameter descriptionoptionalyes6.2.1.252 to 57tab. 17Implementation of parameter description for all parameters.parameter text element is optional. Note that it is not intended that the parameter description is changeable via BMP access. Implement the parameter description fixed and as read only.yesstep 1e
1.8multi parameter accessoptionalyes6.2.3.362, 66support of more than one parameter access per response block.check most recent errata list.yesstep 2
1.9parameter 974optionalyes6.3.9.4157Tab. 116post capability and ressources of the implemented BMP service.recommended especially if the BMP properties differ from the standard setting (244 Byte, multi parameter).yes step 2
1.10parameter 927optionalno6.3.11160Tab. 136post and control write priority for parameter in a vendor specific way.may be used if vendor specific mechanism for write priority is already available and can be mapped.nostep 2b
1.11parameter 980 to 989mandatoryyes6.4.2179Tab. 136post all implemented parameters. Profile specific and vendor specific parameters.You may use only parameter 980 and implement a long list, or you split the parameter list among several list parts using multiple parameters.yesstep2
1.12parameter 990 to 999optionalno6.4.2180Tab. 136post all differences from factory setting.implementation only if there is a dedicated factory setting. Not used very often.nostep2b
1.13vendor specific parameteroptionalyes6.2.258As required map already existing internal parameters, which are not covered by standard Profidrive parameters, to profidrive vendor specific parameters. For vendor specific parameters the number ranges from 1 to 899 and 1000 to 60000 shall be used.useful to access all drive parameters via the Profidrive parameter channel, e.g. from the vendor drive setup tool.yesstep2c
2.0General State MachineBlock-No. 2mandatory
2.1General state machinemandatoryyes6.3.3.1 and 6.3.290, 91 and 82 to 88fig. 27Mapping of drive internal states to PROFIdrive General state machine.Use grafic state diagram Fig. 27 and comments in Tab. 64 to 73 for mapping.yesstep 3a
2.2Bit "pulses enabled" and parameter 924optionalyes6.3.2.588Tab. 74Mapping of internal drive status "pulses enabled" to vendor specific bit in ZSW1 or ZSW2. Implementation of parameter 924 to post the position of the "pulses enabled" bit.Recommended to implement "pulses enabled" status bit on bit 10 of ZSW2 (because Siemens drives do so). Also implement p924.yesstep 3a
2.3STW1 state machinemandatoryyes6.3.2.182 to 84Tab. 64Implementation of STW1 bits 0 to 3 and 10be aware of importance of bit 10yesstep 3a
2.4ZSW1 state machinemandatoryyes6.3.2.385 to 87Tab. 69Implementation of ZSW1 bits 0 to 2 and 4 to 6 and 9be aware of importance of bit 9yesstep 3a
2.5STW2 state machineoptionalno6.3.2.285Tab. 68nothing to do (STW2 only contains vendor specific bits)only if the drive supports a telegramm containing STW2nostep 3b
2.6ZSW2 state machineoptionalno6.3.2.487Tab. 73Implementation of ZSW2 bit 11 "pulses enabled"only if the drive supports a telegramm containing ZSW2nostep 3b
3.0Speed Setpoint ChannelBlock-No. 3mandatory
3.1full speed setpoint channelmandatory AC1AC1 yes6.3.3.2.191 to 92Fig. 29Implementation of functionality controlled by STW1 bits 4, 5, 6. Also implement corresponding status signal ZSW1 bit 8, 10 and 2.Implementation mandatory if drive is a frequency converter AC1.yesstep 4a
3.3parameter 930optional AC1no6.4.2 6.3.3 6.3.3.2174 89 92, 94Tab. 136for pure AC1 drives not necessary or posts always 1nostep 4a
3.4Jog modeoptional AC1no6.3.3.2.395Fig. 29Implementation of the Jog functionality controlled by STW1 bits 8 and 9.Marketing decision if Jog functionalty is necessary.nostep 4b
3.5speed IO Data normalizationmandatoryyes6.3.4.4113 to 115Implementation of signals NSOLL_A, NIST_A, NSOLL_B, NIST_B as N2 or N4 data types, as necessary for planned telegrams.Implement vendor specific parameters for content of NSOLL_A, NSOLL_B, NIST_A, NIST_B. Implement one vendor specific parameter (e.g. 2000) which contains the 100% value for speed data normalization.yesstep 4a
4.0Telegram SelectionBlock-No. 4mandatory
4.1parameter 922mandatoryyes6.3.4.3110Tab. 89Implement telegram selection and post selected telegram via param. 922. Telegramm configuration may be set via write of param. 922 or by dynamic configuration in the communication startup phase (expected configuration).parameter 922 readable is mandatory.define selectable profidrive telegrams as separate submodules in the GSDML.yesstep5a
4.2parameter 915optionalno6.3.4.3111Fig. 41Post selected telegram setup by the list of transfered parameters of the output DO IO Data in param. 915. Flexible telegramm configuration may implemented by writing of param. 915 (if p922 is set to zero). Implementation together with p916.usefull if flexible telegramm configuration shall be used. Precondition is, that all possible telegram signals are mapped to parameters.nostep5b
4.3parameter 916optionalno6.3.4.3111Fig. 41Post selected telegram setup by the list of transfered parameters of the input DO IO Data in param. 916. Flexible telegramm configuration may implemented by writing of param. 916 (if p922 is set to zero). Implementation together with p915.usefull if flexible telegramm configuration shall be used. Precondition is, that all possible telegram signals are mapped to parameters.nostep5b
4.4parameter 923optionalno6.3.4.3111Fig. 41Post mapping of available Signals (signal number) to Profidrive parameters (vendor specific).usefull if flexible telegramm configuration shall be used. Precondition is, that all possible telegram signals are mapped to parameters.nostep5b
4.5parameter 930 optional AC1no6.4.2 6.3.3 6.3.3.2174 89 92, 94Tab. 136post currently active setpoint interface.optionalnostep 5a
4.6parameter 900optionalyes6.4.2172Tab. 136post and/or set DO IO Data output part of the selected profidrive telegram.may be used for diagnostic purpose or to control the drive via acyclic channel (parameter access).nostep5b
4.7parameter 907optionalyes6.4.2172Tab. 136post DO IO Data input part of the selected profidrive telegram.may be used for diagnostic purpose or to control the drive via acyclic channel (parameter access).nostep5b
4.8parameter 928optionalno6.3.11160Tab. 136Implement control priority for setpoint values if control by supervisor is a feature. Implementation of control by supervisor is vendor specific.usefull if vendor specific movement of drive from supervisor (drive configuration tool) is already available and shall be used.nostep5c
5.0Device IdentificationBlock-No. 5mandatory
5.1parameter 964mandatoryyes6.3.9.1154Tab. 110Post general information about Drive Unit (vendor, drive type, hardware version, software version).if helpful vendor specific device information may be added.yesstep 6a
5.2parameter 965mandatoryyes6.3.9.2155Tab. 111Post the supported Profidrive profile version.yesstep 6a
5.3parameter 975mandatoryyes6.3.9.3155Tab. 112Post general information about the DO (DO-ID, vendor, DO type, hardware version, software version, supported AC).yesstep 6a
5.4parameter 962mandatory if data types D2, T2, T4 or R2 are usedyes6.4.2176Tab. 136Post the active sampling time of the device.nostep 6b
5.5parameter 969optionalno6.4.2177Tab. 136Post the operation time since last startup .may be implemented if this service is already available on the device.nostep 6b
5.6parameter 978optionalno8.7.3270Fig. 129Implement the List of all DO-Ids if the device supports BMP-Global parameter access service.parameter is mandatory if BMP-Global service is supported.nostep 6b
5.7parameter 61000optionalno8.10275 to 276Tab. 184Implement the parameter NameOfStation for Profinet interface identification.read only.nostep 6b
5.8parameter 61001optionalno8.10275 to 276Tab. 184Implement the parameter IpOfStation for Profinet interface identification.read only.nostep 6b
5.9parameter 61002optionalno8.10275 to 276Tab. 184Implement the parameter MacOfStation for Profinet interface identification.read only.nostep 6b
5.10parameter 61003optionalno8.10275 to 276Tab. 184Implement the parameter StandardGatewayOfStation for Profinet interface identification.read only.nostep 6b
5.11parameter 61004optionalno8.10275 to 276Tab. 184Implement the parameter SubnetMaskOfStation for Profinet interface identification.read only.nostep 6b
6.0Device ManagementBlock-No. 6mandatory
6.1parameter 970optionalyes6.4.2177Tab. 136Implementation of the loading of the DO (local) parameters from non volatile memory or reset to factory setting (or mapping of this already existing mechanism).should be implemented if the drive/encoder is a complex device. For simple devices (less than 20 parameters) parameter storage should be done via GSD/controller.nostep 7a
6.2parameter 971optionalyes6.4.2177Tab. 136Implementation of the storage of the DO (local) plus global parameters to non volatile device internal memory (or mapping of this already existing mechanism).should be implemented if the drive/encoder is a complex device. For simple devices (less than 20 parameters) parameter storage should be done via GSD/controller.nostep 7a
6.3parameter 977optionalyes6.4.2178Tab. 136Implementation of the storage of all parameter (global, all local of all DO) to non volatile device internal memory (or mapping of this already existing mechanism).should be implemented if the drive/encoder is a complex device. For simple devices (less than 20 parameters) parameter storage should be done via GSD/controller.nostep 7a
6.4parameter 976optionalyes6.4.2178Tab. 136Implementation of the loading of all parameter (global, all local of all DO) from non volatile memory or reset to factory setting (or mapping of this already existing mechanism).should be implemented if the drive/encoder is a complex device. For simple devices (less than 20 parameters) parameter storage should be done via GSD/controller.nostep 7a
6.5parameter 972optionalyes6.3.10158 to 159Tab. 119Implementation of the reset mechanism for the device (DU), or mapping of this already existing mechanism.check most recent errata list.nostep 7a
7.0Device Model PROFINETBlock-No. 7mandatory
7.1define slot/subslot modelmandatoryyes8.4260 to 265Fig. 124According to your drive type select and draw the appropriate Slot and Subslot structure of your drive device according to the definitions in chapter 8.4.3. For homogeneous single or multi axis devices the device structure is quite easy and similar to Fig. 124for homogeneous Profidrive devices (general use case) the device model is quite easy.Get your Vendor-ID from PI. Define Vendor specific Device-ID.yesstep 8a
7.2define DAP modulemandatoryyes8.4.3262The DAP module is slot 0 and represents the device itself. Therefore the module 0 always contains interface submodule and as much port submodules than the device supports physical Profinet ports. Define a Module-ID for your DAP (module). The DAP-Module-ID is vendor specific. Typically the DAP-Module-ID identifies hardware- and software version of the device.define a method to distinguish hardware and software versions of the device by different DAP-Module-Ids. Implement a compatibility check in the Profinet startup to confirm or reject an unequal Module-ID (compatible typically means, that "newer" devices accept "older" module-IDs in the expected configuration but not vice versa.Define Device and DAP Module with all Submodules in the GSDML. The DAP Module and all Submodules in the DAP get the API=0.yesstep 8a
7.3define DO modulesmandatoryyes8.4.3263Define as much DO-Modules than Axis types required for the drive. The Module-ID of the DO-Modules is vendor specific.the Module-ID of the DO-Modules typically represents the axis type and variants of the DO.define Modules for all DO-Types used for this drive. The DO Modules and all Submodules in the DO-Module get the API=0x3A00.yesstep 8a
7.4define Submodulesmandatoryyes8.4.5264Tab. 176 Tab. 177Define one MAP Submodule (Submodule-ID = 0xFFFF). Also define as much telegram Submodules than Profidrive telegrams required for the drive. The lower word of the Submodule-ID is defined by Profidrive Tab. 177. The higher word of the Submodule-ID is vendor specific.the vendor specific part of the submodule ID is used to distinguish submodules having the same telegram type but different isochroneous attributes.define Submodules for all Profidrive telegramms used for this drive dispatch them to the modules defined. All Submodules in the DO-Module get the API=0x3A00.yesstep 8a
7.5Prm parameterizationoptionalnoEncoder Profile V4.1Define and implement a device specific parameterization data record (see Encoder Profile V4.1 for details).Only usefull for small devices with little number of parameters which typically do not have a special drive configuration tool.define PRM data record and available device parameter in the GSDML.nostep8b
8.0Fault BufferBlock-No. 8mandatory
8.1decide fault buffer modelmandatoryyes6.3.8.3149Tab. 106decide if the complete or reduce fault buffer is necessary and decide the fault buffer size. Default is an 8x8 fault buffer size according to fig. 64.for easy devices it may be helpful to reduce the fault buffer size and limit to the reduced fault buffer.yesstep9a
8.2fault number block (p944, p947)mandatoryyes6.3.8.3145 to 151Tab. 106implementation of parameters 944 and 947 and the related fault buffer logic according to the definition in fig. 62 and fig. 63 together with the handling of the bits ZSW1 bit3 and STW1 bit 7 (alarm handling logic).mandatory minimum implementation of the fault buffer. According to the definition a fault always causes the drive to a stop reaction. All other exceptions are warnings.yesstep9a
8.3fault situation counter (p952)optionalyes6.3.8.3145 to 151Fig. 62implementation of parameter 952 and the related fault buffer logic (incrementing and general reset of the fault buffer).optional function. Useful to process a general reset of the whole fault buffer by the user.nostep9b
8.4scaling of the fault buffer (p950)optionalyes6.3.8.3 '6.4.2145 to 151 and 175Tab. 136implementation of parameter 950 to post the real size of the fault buffer.shall be implemented if the size of the fault buffer differs from the default size (8x8).nostep9b
8.5fault time (p948)optionalyes6.3.8.3 '6.4.2145 to 151 and 175Tab. 136implementation of parameter 948 to post time stamp of the fault (vendor specific).usefull to implemented if fault time stamp is already available in the device.nostep9b
8.6fault number list with text (p951)optionalyes6.3.8.3 '6.4.2145 to 151 and 176Tab. 136implementation of parameter 951 to post fault related parameter and fault text.nostep9b
8.7fault value (p949)optionalyes6.3.8.3 '6.4.2145 to 151 and 176Tab. 136implementation of parameter 949 to post fault related fault vaule.nostep9b
8.8fault code block (p945, p946)optionalno6.3.8.3145 to 151 and 174Tab. 106implementation of parameters 944 and 947 and the related fault coding logic according to the definition in fig. 61.useful only if recoding from drive internal (vendor specific) fault codes to free user fault coding is a requirement.nostep9c
8.9fault reactionmandatoryyesAnnex280 to 282Fig. 134implementation of the alarm handling logic according to the definition in fig. 133, fig. 134 and fig. 135.yesstep9a
9.0Warning MechanismBlock-No. 9optional
9.1warning parameters (p953ff)optionalyes6.3.8.2144 to 145Fig. 60map warnings from your drive application to bits in the dedicated warning parameters p953 to p960 in a vendor specific way. Also implement the signalling of present warnings via ZSW1 bit 7.yesstep10
10.0Alarm MechanismBlock-No. 10optional
10.1fault mappingoptionalyes6.3.8.4152 to 153Tab. 105Implement a mapping of present faults (out of the fault buffer) and present warnings (out of the warning parameters) on to the Profidrive fault classes defined in table 109.check most recent errata list for extensions to the Profidrive fault classes. Typical use case for use of the Alarm Channel is when the drive is attached to a standard PLC controller. More sophisticated motion control systems often use the more detailed information out ouf the Profidrive fault buffer.nostep11a
10.2alarm managementoptionalyes8.8.2 to 8.8.4271 to 273Tab. 105Implement signalling of comming and vanishing Profidrive Diagnosis Objects via the Profinet alarm channel by use of profile specific alarms according to the definition in fig. 130 and table 179.Attach the Profidrive Alarm Channel to the MAP submodule of the DO Module. Add functionality to switch on and of the posting of drive alarms via the alarm channel in a vendor specific way (e.g. vendor specific Profidrive parameter).Define Profidrive alams in the GSDML (Type, Text, …).nostep11a
10.3Diagnosis data recordoptionalyes8.8.5273Tab. 105Implementation of the DiagnosisData Record where controller or supervisor can read a list of all currently active alarm objects.nostep11b
14.0Telegram Implementationmandatory
14.1Telegramms AC 1 basicmandatory AC1yes6.3.4.2106Tab. 79Implement basic AC1 standard telegram 1 according to definition in table 79. Necessary signals are all available by predecessor steps.Implementation of standard telegram 1 is still helpfull as an intermediate step even if your drive is dedicated for AC4.define Profidrive telegram 1 as separate Submodule in the GSDML.yesstep15a
14.2Telegramms AC 1 advancedoptional AC1no6.3.4.2106Tab. 80Implement advanced AC1 standard telegram 2 according to definition in table 80. Necessary signals are allready available by predecessor steps.Implementation of standard telegram 2 may be useful if the drive is a high precision servo drive or shall be controlled in isochroneous mode or with life sign supervision.define Profidrive telegram 2 as separate Submodule in the GSDML.nostep15b
14.3Telegramms AC 1 VIK-Namuroptional AC1no6.5.5.1188Implement special AC1 VIK-Namur telegram 20 according to definition in table 140. This may be usefull if your drive is intended to be used in the process industry and/or your customer requires for a VIK-Namur interface.For the implementation of telegram 20 you have to implement also some new signals according to the definition in chapter 6.5. Note that for a real VIK-Namur interface you have to fullfill all requirements stated in 6.5. Also your drive has to match with the VIK-Namur GSD.define Profidrive telegram 20 as separate Submodule in the GSDML.nostep15g
14.4Telegramms AC 1 vendor specificoptional AC1no6.3.4.2106Implement special AC1 vendor specific telegrams according to your own definition. This may be usefull if your drive already has vendor specific additional functionality which should be controlled via telegram.Typical solution is to compose a new telegram by adding additional signals to standard telegram 1 or 2.define Profidrive telegram x as separate Submodule in the GSDML.nostep15c