FAQs (from V3.0)

FAQ #1 How do I integrate one or more axes into a PLC application?

The procedure here differs fundamentally from an axis guided by the NC task, because in this case everything done by the NC task is performed by the PLC. Ready-made function blocks are, however, available in most areas, so that the additional programming effort is held within reasonable limits. The following particular points must be considered:

• Axis data in the PLC application (FAQ #2)
• Initializing and loading the axis parameters when starting the PLC application (FAQ #3)
• Acquisition of actual values (FAQ #4)
• Generating control values (FAQ #5)
• Processing control values in preparation for output (FAQ #6)
• Setting up the axes (Setup)
• Commissioning of actual pressure determination with function blocks of type MC_AxRtReadPressureSingle_BkPlcMc or MC_AxRtReadPressureDiff_BkPlcMc.
• Organization of the procedure for movement (FAQ #7)

If only the usual blocks (encoder, generator, finish, drive) for the axis are to be called, a block of type MC_AxStandardBody_BkPlcMc should be used for simplicity.

FAQ #2 What data has to be created in the PLC application for the axes?

For each axis, one variables of each type Axis_Ref_BkPlcMc, ST_TcPlcDeviceInput and ST_TcPlcDeviceOutput has to be created. The use of variable fields is highly recommended for multiple axes. Examples for one and five axes can be found in the first sample programs.

The procedure using MC_AxUtiStandardInit_BkPlcMc function blocks shown in these examples ensures correct initialization on start-up of the PLC and initiates loading of the axis parameters from files.

Further data are required for realizing message logging. See also FAQ #10.

Further data are required for assigning one's own IDs to customer-specific axis parameters in the PlcMcManager. See also FAQ #13

Further data are required in order to utilize blending according to PLC Open. See also FAQ #20.

FAQ #3 How do I initialize the data for an axis?

A number of initializations must be carried out when the PLC applications starts. This is best done in three stages, which are provided by an MC_AxUtiStandardInit_BkPlcMc function block and should only be realized directly by the application in special cases. They are described here only for the sake of completeness.

1. A number of pointers must be correctly set up to link the components of the axes together. This task should be solved with a function block of type MC_AxUtiStandardInit_BkPlcMc, which detects a shift or change in size in the memory or the change of a type code during a subsequent online change and then ensures that the pointers are reinitialised and the parameters are reloaded.
2. The parameters for the axis must be appropriately set. Although it would be technically possible for the application to do have these assignments hard-coded, this is not usually helpful. It is preferable to save the settings in files, which are loaded on system startup under control of the application through the MC_AxUtiStandardInit_BkPlcMc function block. Notes on setting up an axis can be found under Setup.
3. The task cycle time should be applied in the axis parameters. This should be done at the end of the parameter loading procedure, in order to set this value correctly, in view of the fact that it is important for the function of many function blocks. An MC_AxUtiStandardInit_BkPlcMc function block deals with this task automatically.

If a function block of type MC_AxAdsCommServer_BkPlcMc is used in the application, the function block must be called in the same task that carries out the pointer assignments. If this is not possible, or for some reason difficult, then calling the function block must be prevented while the assignments are being carried out. The result, otherwise, can be that the PLC application crashes as a result of serious runtime errors (Page Fault Exception).

All activities listed here should through be realized and coordinated by an MC_AxUtiStandardInit_BkPlcMc function block. If the nInitState variable in Axis_Ref_BkPlcMc of the axis adopts either the value 2 or -2, then the initialization has been successful or has ended with an error. If the initialization is successful, MC_AxUtiStandardInit_BkPlcMc.Ready and bParamsEnable in Axis_Ref_BkPlcMc are TRUE, otherwise this variable remains FALSE.

The sample programs provided specify the name of the axis and the name (included the path) of the corresponding parameter file. It is essential that these specifications are modified to match the particular application.

FAQ #4: How is the actual position of the axes determined?

A range of signal transducers may be considered for use as position sensors, operating according to a variety of physical principles to generate a position-dependent electrical magnitude. This magnitude determines the type of I/O components that must be used. The variables of types ST_TcPlcDeviceInput and ST_TcPlcDeviceOutput must be created for each axis, and contain elements that are to be linked to the actual value, counter, latch, control and status variables associated with the I/O hardware.

Here are a few examples:

If one of the components mentioned here is used, then one of the encoder function blocks provided will usually be applied. The interfaces of these function blocks are not guaranteed and should therefore not be called directly by the application. It is better to set the encoder type according to the constants in E_TcMcEncoderType under nEnc_Type in ST_TcHydAxParam, and to use a function block of type MC_AxRtEncoder_BkPlcMc. This then automatically calls the correct type of sub-function-block for the type concerned.

All encoder function blocks use the parameters fEnc_IncWeighting and fEnc_IncInterpolation as increment assessment. fEnc_ZeroShift is also used as a zero shift for absolute displacement sensors. Incremental sensors usually require a reference travel using a MC_Home_BkPlcMc function block, during which fEnc_RefShift in ST_TcHydAxRtData is determined. This value then does the job of the zero shift. It goes without saying that in special cases the zero shift can also be defined with an MC_SetPosition_BkPlcMc function block. The referenced status of the axis should be defined with MC_SetReferenceFlag_BkPlcMc().

If it is not possible to determine the actual position with function blocks from the library for technical reasons, this task can be handled by application function blocks, and the result can be entered in fActPos, and fActVelo can be entered in ST_TcHydAxRtData, if required. For the sake of uniformity use should again be made here of the fEnc_IncWeighting, fEnc_IncInterpolation and fEnc_ZeroShift or fEnc_RefShift parameters.

If only the usual function blocks (encoder, generator, finish, drive) for the axis are to be called, a function block of type MC_AxStandardBody_BkPlcMc should be used for simplicity.

Commissioning of an actual pressure determination with function blocks of type MC_AxRtReadPressureSingle_BkPlcMc or MC_AxRtReadPressureDiff_BkPlcMc is described in the documentation for the function block.

FAQ #5: How is the control value for an axis created?

In each cycle, the PLC application must call a function block of type MC_AxRuntime_BkPlcMc, or alternatively a suitable controller function block (e.g. a pressure regulator) for each axis. The parameter nProfileType in ST_TcHydAxParam specifies the procedure that is to be used to generate the control value. Velocity control values are calculated here according to the type, and depending on other parameters associated with the axis and on the movement data. These control values are, however, normalized to the abstract numerical range ±1.0, and have not yet been prepared for immediate output to I/O hardware.

If only the usual function blocks (encoder, generator, finish, drive) for the axis are to be called, a function block of type MC_AxStandardBody_BkPlcMc should be used for simplicity.

FAQ #6: How is the control value for an axis prepared for output?

After calling the MC_AxRuntime_BkPlcMc function block, a function block of type MC_AxRtFinish_BkPlcMc must be called for each axis. This function block assembles a number of velocity components (control value, controller output, offset compensation, overlap compensation), and also takes into account in the bends in the feed forward characteristic curve.

Numerical adjustment is usually necessary prior to output to an I/O module. An MC_AxRtDrive_BkPlcMc function block is to be called for each axis for this purpose. The value of nDrive_Type in ST_TcHydAxParam selects the hardware-specific sub-function-block to be used.

The variables of types ST_TcPlcDeviceInput and ST_TcPlcDeviceOutput must be created for each axis, and contain elements that are to be linked to the set value and control variables of the I/O hardware.

If only the usual function blocks (encoder, generator, finish, drive) for the axis are to be called, a function block of type MC_AxStandardBody_BkPlcMc should be used for simplicity.

FAQ #7: How is the control value output to an axis?

A range of devices and equipment might be functioning as actuators, applying a variety of physical principles to create a variable velocity that depends on an electrical magnitude. This magnitude determines the type of I/O components that must be used. The variables of types ST_TcPlcDeviceInput and ST_TcPlcDeviceOutput must be created for each axis, and contain elements that are to be linked to the variables of the I/O hardware.

Here are a few examples:

If one of the components mentioned here is used, then one of the drive function blocks provided will usually be used. These interfaces of these function blocks are not guaranteed and should therefore not be called directly by the application. It is better to set the drive type according to the constants in E_TcMcDriveType under nDrive_Type in ST_TcHydAxParam, and to use a function block of type MC_AxRtDrive_BkPlcMc.

If only the usual function blocks (encoder, generator, finish, drive) for the axis are to be called, a function block of type MC_AxStandardBody_BkPlcMc should be used for simplicity.

FAQ #8: In what order should the function blocks of an axis be called?

1. Obligatory: all function blocks, which detect the actual status of the axis. These include function blocks of types MC_AxRtEncoder_BkPlcMc, MC_AxRtReadPressureDiff_BkPlcMc or MC_AxRtReadPressureSingle_BkPlcMc.
2. Usual: function blocks or commands, which update the enable signals of the axis. This is usually a function block of type MC_Power_BkPlcMc. For axes with an incremental encoder, which is referenced using a cam, a function call MC_AxRtSetReferencingCamSignal_BkPlcMc is used in addition.
3. Optional: Function blocks, which derive a decision or trigger a command based on an actual axis status, an I/O signal or an application signal. For example, an axis start can be triggered in response to the signal of a proximity limit switch, or an axis movement can be stopped before the target position is reached, depending on the pressure increase.
4. Obligatory: Control value generators such as function blocks of type MC_AxRuntime_BkPlcMc.
5. Optional: Various controllers can be called at this point, as required. This can be a function block of type MC_AxCtrlSlowDownOnPressure_BkPlcMc or similar.
6. Obligatory: An adaptation function block of type MC_AxRtFinish_BkPlcMc.
7. Optional: If required, a function block for the automatic commissioning can be called at this point.
8. Obligatory: An output function block of type MC_AxRtDrive_BkPlcMc.

Instead of the library function blocks, application function blocks can be used. However, one should check carefully whether this is necessary, in which case compatibility with the library must be ensured. In some applications this may become necessary, in order to adapt a non-standard sensor or actuator, or to solve a special control task.

FAQ #9: How do I control a valve output stage (on-board or externally)?

The ST_TcPlcDeviceOutput structure is intended for the bPowerOn and bEnable signals and for controlling the output stage supply and activation. Both signals are set by function blocks of type MC_Power_BkPlcMc, if the input Enable is set. At the same time this function block sets the software controller enable in ST_TcHydAxRtData.nDeCtrlDWord.

The ST_TcPlcDeviceInput structure is intended for the signals bPowerOk, bEnAck and bReady for the output stage supply control, feedback from the output stage activation and the status signal. The differences in the signals provided by different manufacturer can be very significant. Currently, only the bPowerOk signal is used for specifying the Status output of the MC_Power_BkPlcMc function block. If no suitable signal is available, or if no monitoring is to be realised, ST_TcHydAxParam.bDrive_DefaultPowerOk should be set.

FAQ #10: How do I create a message buffer?

Direct output of messages from the function blocks would result in runtime variations that would be difficult to calculate. For this reason, the messages are stored in a buffer and output in the Windows Event Viewer one after another, if required.

In order to be able to use a message buffer, a variable of type ST_TcPlcMcLogBuffer must be created. This buffer is used to hold the messages from all axes. It is important that only one such variable is created in the project, irrespective of the number of axes. The address of this buffer should be transferred to the MC_AxUtiStandardInit_BkPlcMc function blocks of all axes, together with the addresses of the other individual axis components. This function blocks are usually called in the initialization part of the project. This address is stored in the element pStAxLogBuffer in the structure Axis_Ref_BkPlcMc and by the function block.

nLogLevel in Axis_Ref_BkPlcMc is used to specify the significance level threshold for storing messages in the buffer. The values to be used are defined in the global variables of the library. Note that this setting is required for each axis.

The library function blocks detect the preparations mentioned above and will commence issuing messages. However, if the message output is enabled, the buffer would fill up quickly and not accept further messages. There are two ways to avoid this.

FAQ #10.1: Passing on messages to the Windows Event Viewer

In order to transfer messages from the LogBuffer of the library to the Windows Event Viewer, a function block of type MC_AxRtLoggerSpool_BkPlcMc should be called cyclically. Witch each call a message is removed from the LogBuffer.

Computers running Windows CE are also capable of amending an Event Viewer for the messages created by TwinCAT. To this end this service is emulated by the TwinCAT system service. However, usually only a flash disk will be available. In order to avoid overloading the relatively small message capacity of the Event Viewer, only errors should be logged.

FAQ #10.2: Deleting the oldest messages

In order to ensure a minimum number of messages that can be handled, a function block of type MC_AxRtLoggerDespool_BkPlcMc should be called cyclically. With each call, this function block removes the oldest message from the LogBuffer, until a transferred number of free messages is available. The deleted messages are lost.

FAQ #10.3: Generating logger entries through the application

An application can output a message either axis-related or non-axis-related. The function blocks MC_AxRtLogAxisEntry_BkPlcMc and MC_AxRtLogEntry_BkPlcMc are available for this purpose.

FAQ #10.4: Library-internal message buffer

A cyclic call to the MC_Communications_BkPlcMc function block uses a library-internal message buffer. For this purpose, the MC_Communications_BkPlcMc function block references the internal message buffer in the transferred axes and calls the MC_AxRtLoggerSpool_BkPlcMc function block. A message buffer created in the PLC application is no longer required here. In addition, the message buffer referenced when calling MC_AxUtiStandardInit_BkPlcMc is ignored when calling the MC_Communications_BkPlcMc function block.

FAQ #11: How do I abort monitoring of a function?

Some library function blocks start an activity, for which cyclic calling is no longer essential. However, these function blocks are also structured according to the rules of the PLCopen Motion Control guidelines in such a way that they fully monitor the activity and present it at their outputs. This is indicated by the output Busy, which most function blocks provide.

Omitting the cyclic call of a function block that is in this monitoring state would usually result in significant problems. The next function start with the respective function block would have problems with evaluating the edges at its inputs, or it would detect that meanwhile the axis has executed another function and indicated a problem that doesn't exist (CommandAborted).

In older versions of the library a function block of type MC_AxUtiCancelMonitoring_BkPlcMc() was provided, which for a few motion functions aborted the monitoring by the function block initiating the function. This function block is no longer required, in view of the fact that in the meantime the PLC Open rules have been implemented more fully.

To instruct a function block to terminate monitoring its function, in most cases it is sufficient to call it once or several times with Execute:=FALSE. This applies in particular to MC_MoveAbsolute_BkPlcMc(), MC_MoveRelative_BkPlcMc() and MC_MoveVelocity_BkPlcMc().

Subsequently, a new functionality can be started in same or a later cycle with the same function block or an instance of the same or another type. This procedure can be repeated as required.

Complex functions composed of several sub-actions, such as MC_Home_BkPlcMc(), require the continuous calling of the function block as the latter organizes the required processes itself ( MC_Home_BkPlcMc ())

FAQ #12: How do I monitor the communication with an I/O device?

ST_TcPlcDeviceInput and ST_TcPlcDeviceOutput variables provide an element with the name uiBoxState. If the Bus Couplers or the interface cards of the power units used offer a corresponding variable and the variable assumes the value 0 with undisturbed communication in the fieldbus used, a link should be created. This is possible, for example, with Beckhoff Lightbus and Real-time Ethernet. If an MC_Power_BkPlcMc function block is used for the axis, the function block monitors the uiBoxState and reports problems with the communication. In such a case the axis is put in an error state.

EtherCAT offers enhanced options.

FAQ #13: How do I assign my own labels to customer-specific axis parameters?

The Axis_Ref_BkPlcMc structure uses the pAuxLabels pointer to support the application of an array of texts, which are displayed by the PlcMcManager. These texts can be loaded by the MC_AxUtiStandardInit_BkPlcMc function block when the application is started from a file. To this end this function block must be provided with the address of an ST_TcMcAuxDataLabels variable and a suitable file.

It goes without saying that it is also possible to define the elements of the ST_TcMcAuxDataLabels variable through direct assignment from the application. In this case, the file is not required.

A number of controller function blocks of the library define the arrays texts automatically.

FAQ #14: How do I control a current valve?

In contrast to a 4/2 or 3/2 directional proportional valve or a servo-valve, a current valve is controlled with a 0..10 V signal (if a valve output stage is present) or actuated with a load-independent current of 0...I_Nominal. In this control, only the magnitude of the velocity is transferred. The direction is transferred not with the sign, but by other means. This usually requires digital signals, which are used for controlling switching valves. The ST_TcPlcDeviceOutput structure provides elements such as bBrakeOff, bMovePos and bMoveNeg for this purpose. For generating an absolute control value, bDrive_AbsoluteOutput should be set in the axis parameters.

This also enables the use of conventional frequency converters with asynchronous motor, encoder and brake, if the converter provides an analog input.

FAQ #15: Which axis variables should be logged with the Scope?

The following signal composition is recommended:

• Always: actual axis position: Axis_Ref_BkPlcMc.ST_TcHydAxRtData.fActPos: in actual value units, as specified by the encoder scaling.
• Only for gear or synchronization coupling, cam plate: set axis position: Axis_Ref_BkPlcMc.ST_TcHydAxRtData.fSetPos: in actual value units, as specified by the encoder scaling.
• Particularly during commissioning: actual velocity value: Axis_Ref_BkPlcMc.ST_TcHydAxRtData.fActVelo: velocity in physical representation.
• Particularly during commissioning: Residual distance or target position: Axis_Ref_BkPlcMc.ST_TcHydAxRtData.fDistanceToTarget or Axis_Ref_BkPlcMc.ST_TcHydAxRtData.fTargetPos: in actual value units, as specified by the encoder scaling.
• Only if pressure/force logging is active: various actual pressure and force values: in Axis_Ref_BkPlcMc.ST_TcHydAxRtData: as required fActPressure fActPressureA fActPressureB fActForce fValvePressure fSupplyPressure: pressures and forces, unit is defined through parameterization of the logging function blocks.
• Particularly during commissioning: velocity control value: Axis_Ref_BkPlcMc.ST_TcHydAxRtData.fSetVelo: velocity in physical representation.
• Particularly during commissioning: controller output: Axis_Ref_BkPlcMc.ST_TcHydAxRtData.fLagCtrlOutput: velocity in physical representation.

The signal selection in ScopeView is simplified if the Axis_Ref_BkPlcMc variables contain a name that begins with aaa_. This approach is used in the sample programs and ensures that the variables can be found quickly in the symbol list.

In the signal composition of ScopeView, channels can be temporarily disabled. In this way it is possible to maintain a comprehensive configuration but limit logging to data that are currently of interest.

FAQ #16: What is the purpose of the variable nDebugTag in Axis_Ref_BkPlcMc?

This variable exists in some versions. It has no meaning for the PLC project.

This variable is used by nearly all library function blocks to store a unique ID for the duration of their execution. To this end the content that was found is stored in a local variable of the function block and restored immediately before the function block is exited.

Should the program crash, or if there is a suspicion that there was a problem in a library function block, the nDebugTag variables of all axes should be checked. If a value <> 0 is present, the function block was affected by the crash, and the reason should be investigated. The numeric values used are listed in the library under "Global constants". In addition, the contents of ST_TcHydAxRtData.sTopBlockName should be determined. Usually, the name of the function block called directly by the application can be found here.

FAQ #17: What has to be taken into account when Sercos drives are used?

If Sercos drives (from V3.0.26) are used, the following rules must be followed:

• The Sercos master interface (e.g. FC7501 etc.) must be allocated the name "SercosMaster" in the System Manager. Otherwise neither control of the Sercos phase nor parameter and diagnostics communication is possible.
• Only a Sercos segment with the library can be used.
• In the System Manager, the drive devices at the Sercos Segment should be allocated the name under which they are known to the library by calling the MC_AxUtiStandardInit_BkPlcMc() function block. Otherwise neither control of the Sercos phase nor parameter and diagnostics communication is possible.
• The input variable SystemState of the Sercos master interface should be linked for each drive device of the Sercos segment.
• If one or several drives at the Sercos segment are reset, the segment can interrupt the fieldbus. In this case, the Sercos master interface will undergo a corresponding phase change. Usually, the startup up to phase 4 will be automatic. Then:
• the axis addressed by the reset will be error-free, as long as there are no ongoing problems.
• all other axes at the Sercos segment will be in error state (fieldbus failure, axis not ready for operation). Once the triggering reset of the first axis has been processed, the other axes can usually be brought into an error-free state through a reset without a phase change.
• This behavior is determined by characteristics of the Sercos fieldbus and cannot be influenced by the library. It must be taken into account in the application in a suitable manner.
• Depending on certain parameter settings of the drive actuator, axis parameters are determined automatically or have to be specified manually:
• S-0-0076, bits 0 to 2 specify the weighting type of the position data. Supported features:
• a) 0 0 1 translatory weighting:
  S-0-0123 defines the rotation resolution (encoder-interpolation). The revolutional feed rate is calculated from this number and the weighting (S-0-0077, S-0-0078).
• b) 0 1 0 rotary weighting:
  S-0-0079 defines the rotation resolution (encoder-interpolation). The revolutional feed rate has to be set manually.
• S-0-0044, bits 0 to 2 specify the weighting type of the velocity data. Supported features:
• a) 0 0 1 translatory weighting:
  The velocity control value is converted to a velocity in encoder increments per time, based on the revolutional feed rate and the rotation resolution. This information is offset against the velocity resolution (S-0-0045, S-0-0046) and output.
• b) 0 1 0 rotational weighting
  The velocity control value is converted to a speed based on the revolutional feed rate and output.
• S-0-0091 is converted with the method described above for velocity control values and used as reference velocity. If the maximum speed exceeds the value determined in this way, it is limited accordingly.

FAQ #18: How is a pressure or a force determined?

To determine an actual pressure or an actual force, one or several function blocks of types MC_AxRtReadPressureDiff_BkPlcMc, MC_AxRtReadForceDiff_BkPlcMc, MC_AxRtReadForceSingle_BkPlcMc or MC_AxRtReadPressureSingle_BkPlcMc have to be called for each axis. Details for the call sequence can be found under FAQ #8.

The AD converter values to be transferred to the function blocks have to be linked with allocated variables of the application. Details regarding selection and parameterization can be found in the function blocks descriptions.

FAQ #19: What has to be taken into account when AX5000 drives are used?

For AX5000 devices, a number of IDNs are read from the device, and a number of different parameters are calculated automatically.

The following parameters are thus set automatically and cannot be influenced via the PlcMcManager:

FAQ #20: How do I prepare an axis for blending based on PLC Open?

In Hydraulik.lib it is possible to command up to 12 buffered movements. For this purpose, a command buffer of type ST_TcPlcCmdCmdBuffer_BkPlcMc must be passed to the MC_AxUtiStandardInit_BkPlcMc function block for updating the axis reference and a function block MC_AxRtCmdBufferExecute_BkPlcMc must be called cyclically.

If Move function blocks such as MC_MoveAbsolute_BkPlcMc, MC_MoveRelative_BkPlcMc or MC_MoveVelocity_BkPlcMc are now activated, they enter their data in the command buffer.

In buffered mode make sure that the Move function blocks and the MC_AxRuntime_BkPlcMc function block of the axis run in a PLC task.

Transition between a slow and a fast section.

Transition between a fast and a slow section.

FAQ #21: How can I access registers of a terminal, to which an encoder or a valve of an axis is connected?

For register communication with terminals to which the encoder or the valve of an axis is connected, it is recommended to use function blocks of types MC_AxUtiReadRegDriveTerm_BkPlcMc(), MC_AxUtiReadRegEncTerm_BkPlcMc(), MC_AxUtiWriteRegDriveTerm_BkPlcMc() and MC_AxUtiWriteRegEncTerm_BkPlcMc().

FAQ #22: What is the structure of an ASCII file for a linearization table?

The format of an ASCII file from a linearization table is specified as follows:

• One linearization point per row.
• For each row first a velocity value, then an output value.
• The velocity values are normalized to the reference velocity. They are therefore in the range -1,000 to 1,000 inclusive.
• The output values are normalized to the full scale value. They therefore cover the range -1,000 to 1,000.
• The first value in a row may be preceded by white space characters (space, tab).
• Between the two values in row there must be at least one white space character (space, tab).
• Between the two values of a row there may be further white space characters (space, tab).
• Point and comma are permitted as decimal separator.
• No non-digits are permitted between a negative sign and the first digit.
• The first point specifies the negative end of the table.
• The velocity value of all further points must be higher (i.e. less negative or more positive) than its predecessor.
• It makes sense if the output value of a point is higher (i.e. less negative or more positive) than its predecessor, since otherwise there would be a negative slope in this section. This would result in a change of sign of the gain and therefore instability in an active control.
• The zero point (i.e. both coordinates of the point are 0.000) has to be specified.

Example: The following (idealized) table describes a cylinder, which in negative direction only reaches half the velocity of the positive direction due to asymmetric effective areas (due to single-sided piston rod). It is assumed that the cylinder is operated with a zero overlap valve with a bend in the characteristic curve at 40%

FAQ #23: How can PlcMcManager commands be blocked?

In some situations the triggering of commands by the PlcMcManager can be problematic. This would be the case if a certain sequence of actions has to be processed completely, for example. In order to prevent inadvertent issuing of commands by the PlcMcManager in such cases, the MC_AxRtCommandsLocked_BkPlcMc function can be used to enter a lock in the status double word of the axis. If this lock is active, any command sent by PlcMcManager sent is rejected with a write protection error.

It is essential to remove the lock, once the action to be protected has been processed. This also and in particular applies in the event of errors.

An example is available.

FAQ #24: What format do files with characteristic curve data have?

If an axis is equipped with components for a characteristic curve-controlled linearization, the interpolation points can be exported to a file using a function block of the type MC_LinTableExportToAsciiFile_BkPlcMc(). The function block MC_LinTableImportFromAsciiFile_BkPlcMc() is available if such data are to be imported from a file created or modified in this way or in other ways.

So that such files can be used, the following format must be strictly adhered to.

• A row must be used for each point.
• Each row must be terminated with CR/LF.
• Each row initially contains the normalized velocity value in the range -1.0 to 1.0.
• After at least one separator (space or tab), the normalized output value follows for the full range from -1.0 to 1.0.
• The output value must exhibit a constant step size (distance between two points).
• The first row contains the negative end value. Its output value must be -1.0.
• The last row contains the positive end value. Its output value must be 1.0.
• A row must be provided for the output value 0.0.
• The file must therefore contain the same number of points in the negative and positive range. The total number must be odd.
• Both the velocity and the output value follow the same rules:
• Sign with negative numbers
• A digit
• A decimal separator: comma or point
• At least one decimal place
• Optional: An exponent, marked with "e", a minus sign and a digit
• Example: -1.81408951053528e-1 -5.0e-1
• Example: 0.333 0.5