WHAT ARE THE DIFFERENCES BETWEEN ZELIO LOGIC AND TWIDO HARDWARE?

WHAT ARE THE DIFFERENCES BETWEEN

ZELIO LOGIC AND TWIDO HARDWARE?

Function Blocks for Motion Control Version 2.0 Released (Merge of Part 1 and 2)

Introduction

Part 1, the Basic document (version 1.0) was originally published in November 2001, a specification of an independent library of function blocks for motion control. It included motion functionality for single axes and multiple axes, several administrative tasks, as well as a state diagram. This specification provides the user a standard command set and structure independent of the underlying architecture. This structure can be used on many platforms and architectures. In this way one can decide which architecture will be used at a later stage of the development cycle. Advantages for the machine builder are, amongst others, lower costs for supporting the different platforms and the freedom to develop application software in a more independent way, without limiting the productivity of the machine. In addition to those benefits, system maintenance is easier and the education period is shorter. This is a major step forward, and is more and more accepted by both users as well as suppliers. With so many implementations, as well as the first applications, inconsistencies were found in the first specification, as well as additional features to be added. This resulted in an update of the basic document; version 1.1, which was released in April 2005 and implemented in over 30 products.
Part 2, Extensions is an addition to the basic document and should not be seen as a stand alone document. For example, part 2 adds information to the state diagram, but only the added transitions are shown in this document, containing additional function blocks. 
In 2007 we started a new phase in PLCopen Motion Control – the update of the basic specification, known as Part 1 – Basics, and Part 2 - Extensions. With multiple implementations and many applications running, more and more feedback came in at PLCopen for items to be clarified or changed, as well as additions. All these comments were merged in 2 new documents: a “Corrigendum” for the clarifications and changes, and an “Addendum” for the additions. (Note: these documents at the current stage are only open for PLCopen members). This resulted in the decision to merge Part 1 and Part 2 into one document in order to provide a better overview of these basics. This document is now released Version 2.0

Definition of the state machine

The following diagram normatively defines the behavior of the axis at a high level. This diagram is useful to build a more complicated profile or to treat exceptions within a program. (In real implementations there may be additional states at a lower level defined).
The axis is always in one of the defined state (see diagram). Any motion command is a transition that changes the state of the axis and, as a consequence, modifies the way the current motion is computed.

There are eight states defined as shown in the picture below:

  A normal procedure would start in Disabled. In this state the power can be switched on per axis (via the command Power, see above) which transfers the relevant axis to the state Standstill. From there one can access the Homing state (via the issue of the command Home per axis), which after normal completion returns to Stand Still. From here one can transfer an axis to either Discrete Motion or Continuous Motion. From these states a coupling to a master axis can be realized for instance via issuing MC_GearIn. The resulting state for the slave axis is then Synchronized Motion. Issuing a single axis move command will bring the axis back to either Discrete or Continuous Motion. Via the state Stopping one can return to StandStill. ErrorStop is a state the axis transfers to in case of an error. Via a (manual) Reset command one can return to StandStill, from which the machine can be moved to an operational state again. Please note that the States define the functionality of the Function Blocks.

Function Blocks Definitions

A. Axis Ref

The reference to an axis is done via the derived datatype AXIS_REF. This datatype is supplied by all manufacturers. It provides the interface towards the motor / drive itself. The technicalities of the real interface are hidden within the structure and function block itself. In this way, different architectures, from centralized to distributed and networked systems, looks the same to the user while giving access to all relevant parameters.

B. AxisRef as Var_In_Out

The Axis_Ref is used as Var_In_Out, represented as an input and an output connected by a horizontal line in a graphical representation of a Function Block. The variables used within Axis_Ref, acting both as input and output parameters, can be modified within the Function Block as well as receive values from external variables. However they are stored externally to the FB, making copying of the structure unnecessary.
As an example of how this could operate: imagine a Program containing several function blocks, all linked after each other (left-to-right) and all referring to the same axis via Axis_Ref. The first FB reads the latest values in Axes_Ref, and might update some of these values before it finishes its execution. Then the next FB is started and reads the updated values within Axes_Ref, so uses the latest values. And these values are internally coupled to the motor itself. Again, the control architecture can be quite different across systems.
One can use this reference to define one or more virtual axes, in that sense that it exists as a datastructure but is not coupled to a physical drive and/or motor.

The Function Blocks for single axis Motion Control

There are motion related and administrative function blocks defined in both part 1 and 2. The first movement function block is shown here in some more detail:

FB-Name	MC_MoveAbsolute
This function block commands a controlled motion at a specified absolute position.

Graphical representation:  

		MC_MoveAbsolute
AXIS_REF		Axis		Axis		AXIS_REF
BOOL		Execute		Done		BOOL
REAL		Position		Busy		BOOL
REAL		Velocity		Active		BOOL
REAL		Acceleration		CommandAborted		BOOL
REAL		Deceleration		Error		BOOL
REAL		Jerk		ErrorID		WORD
MC_Direction		Direction
MC_BufferMode		BufferMode

The other single axis Function Blocks as defined in part 1 and 2 are listed here below in short-form:

• MC_MoveRelative - moves the axis a specified distance relative to the actual position at the time of the execution. 
• MC_MoveAdditive - for a specified relative distance additional to the original commanded position in the discrete motion state. In the Continuous Motion the specified relative distance is added to the actual position at the time of the execution.
• MC_MoveSuperimposed - for a specified relative distance additional to an existing motion. The existing Motion is not interrupted, but is superimposed by the additional motion. 
• MC_MoveVelocity - for a never ending controlled motion at a specified velocity.
• MC_MoveContinuous - commands a controlled motion of a specified relative distance ending with the specified velocity.  
• MC_TorqueControl - continuously exerts a torque or force of the specified magnitude, approached using a defined ramp, and sets the InTorque output if the torque level is reached.
• MC_SetPosition - shifts the coordinate system of an axis by manipulating both the set-point position as well as the actual position of an axis with the same value without any movement caused.
• MC_SetOverride - sets the values of override for the whole axis and all functions that are working on that axis.  
• MC_TouchProbe - is used to record an axis position at a trigger event.
• MC_AbortTrigger - is used to abort function blocks which are connected to trigger events (e.g. MC_TouchProbe).
• MC_DigitalCamSwitch - provides the analogy to switches on a motor shaft: it commands a group of discrete output bits to switch in analogy to a set of mechanical cam controlled switches connected to an axis. Forward and backward movements are allowed.  
• MC_Home - commands the axis to perform the «search home» sequence. The details of this sequence are manufacturer dependent and can be set by axis’ parameters, as well as the function blocks as defined in Part 5 – Homing sequences.  
• MC_Stop - commands a controlled motion stop and transfers the axis to the state “Stopping”. It aborts any ongoing function block execution. With the Done output set, the state is transferred to the StandStill. While the axis is in state Stopping, no other FB can perform any motion on the same axis.  
• MC_Halt - commands a controlled motion stop. It aborts any ongoing function block execution. The axis is moved to the state “DiscreteMotion“, until the velocity is zero. With the Done output set, the state is transferred to StandStill.  
• MC_Power - switches the power stage on or off.
• MC_ReadStatus - returns in detail the status of the axis with respect to the motion currently in progress.  
• MC_ReadAxisError - Indicates errors not relating to the function blocks.
• MC_Reset -makes the transition from the state ErrorStop to StandStill by resetting all internal axis-related errors and clearing pending commands.
• MC_ReadParameter & MC_ReadBoolParameter - Returns the value of a vendor specific parameter.  
• MC_WriteParameter & MC_WriteBoolParameter - Modifies the value of a vendor specific parameter.
• MC_ReadActualPosition - returns the actual position.
• MC_ReadDigitalInput - provides the value of the digital input as referenced by INPUT_REF.  
• MC_ReadDigitalOutput - - provides the value of the digital output as referenced by OUTPUT_REF.  
• MC_WriteDigitalOutput - writes a value to the output referenced by the argument “Output”once.
• MC_ReadActualVelocity - returns the value of the actual velocity as long as enabled.
• MC_ReadActualTorque - returns the value of the actual torque as long as enabled.  
• MC_PositionProfile - commands a time-position locked motion profile.
• MC_VelocityProfile - commands a time-velocity locked motion profile.
• MC_AccelerationProfile - commands a time-acceleration locked motion profile.
   

Common set of multi-axes Function Blocks

For multi-axes, coordinated movements, a small set is defined. This set will be extended by additional application specific libraries. The current defined Function Blocks are:

• CamTableSelect - selects the CAM tables by setting the pointers to the relevant tables.
• CamIn - engages the CAM.
• CamOut - disengages the Slave from the Master axis immediately.
• GearIn - commands a ratio between the velocity of the slave and master axis.
• GearOut - disengages the Slave from the Master axis.
• MC_GearInPos - commands a gear ratio between the position of the slave and master axes from the synchronization point onwards.

A. Aborting, merging, and blending

Multiple function blocks have an input to set the different operating modes, combined with an output for signalling this. With this input, the FB can either work in a ‘Non-buffered mode’ (default behavior) or in a ‘Buffered mode’. The difference between those modes is when they should start their action:

• A command in a non-buffered mode acts immediately, even if this interrupts another motion
• A command in a buffered mode waits till the current FB is done (signaled via the corresponding output or via in-position, or in-velocity or similar outputs).

The following modes have been identified:

• Aborting - Default mode without buffering. The next FB aborts an ongoing motion and the command is affecting the axis immediately;
• Buffered - The next FB is affecting the axis as soon as the previous movement is ‘Done’. There is no blending;
• BlendingLow - The next FB is controlling the axis after the previous FB has finished (equal to buffered), but the axis may not stop between the movements. The velocity is blended with the lowest velocity of both commands (1 and 2) at the first end-position (1);
• BlendingPrevious - blending with the velocity of FB 1 at end-position of FB 1;
• BlendingNext - blending with velocity of FB 2 at end-position of FB1;
• BlendingHigh - blending with highest velocity of FB 1 and FB 2 at end-position of FB1.

An example

The following example is an example of a simple drilling unit:



We use Sequential Function Chart here to describe the different step for this drilling example.  
Step 1: Initialization, for instance at power up.
Step 2: Move forward to drilling position and start driller turning: in this way it will be fully operational         before the position is reached; then check if both actions are completed.
Step 3: Drill the hole.
Step 4: After Drilling the hole we have to wait for the step-chain sequence to finish dwelling the hole free of any stuff which might have stuck in the hole.
Step 5: Move driller back to starting position and shut the spindle off. Combining the finishing of moving backwards and stopping the spindle we signal the step-chain to start over.

Representation of the drilling example in SFC

The corresponding timing diagram for the movement is depending on the selected mode. For example:


Timing diagram for drilling - aborting mode  

Timing diagram for drilling - blending mode

IEC 1131 or 61131 : status of the Standard

What about this '6' in IEC 1131 ?

The International Electrotechnical Commission, IEC, is a world wide standardization body. Nearly all countries over the world have their own, national standardization bodies. In Germany for instance this is the Deutsche Elektrotechnischen Kommission, DKE. These commissions have agreed to accept the IEC approved and published standards. At local publication, often after translation, the standard was published under a local number. This local number often had no match to the number of the IEC published standard. For a standardization body this looked awkward. To harmonize this, they searched for a world wide numbering system that was available to use. This is where the famous '6' came in. And so IEC 61131-3 became IEC 61131-3, without any changes to the standard itself. Moreover, during the current transition phase, you have to order the IEC 6-1131 standard to get a publication that clearly has on its front cover 'IEC 61131-3'. As this might be confusing to non-insiders, we decided to wait for a new edition of the standard to migrate to the new number. In this way it is coupled to change.

A New Edition?

The international standard "IEC 61131-3" was released in 1993 and, since its adoption, has become widely accepted by the international user and vendor community. Today, it is, as such, the worldwide recognized standard for programming and configuring industrial control devices.

There are, however, several reasons why the standard must be revised: First of all, since 1993 a great deal of practical experience has been gained in which a number of inconsistencies and contradictions have been detected. In order to remedy this, many users of the standard proposed revisions and enhancements. These can be found in the Addendum and in the Corrigendum as belonging to the standard.

In addition, the demands on industrial control systems and their engineering environments have considerably changed over the years, where the most important item is the migration of large centralized control systems towards distributed systems.

This is the reason why IEC 1131 is now being revised in three stages, each summarized below:

1. "Corrigendum": correction of hard errors and non-compliances.
2. "Amendment": more consistent structuring of the standard accompanied by additional implementation of features required in everyday controls situations.
   
3. Harmonization between IEC 61131-3 and distributed systems standards like IEC 61499.

In the course of this, the major goal to maintain upward compatibility for all amendments. This means, a control program which complies with the previous standard is also expected to comply with the new standard without conflicts.

Current state

The new edition of the standard has been published as International Standard in 2003. This new version includes the "Corrigendum" and "Amendments".

The third proposed stage is in a much less mature development stage. This planned harmonization work can lead to a third edition of the standard.

To keep them alive, standards are always subject to change and undergo evolutionary changes in regard to technology advancements and market needs. On the other hand, the essentials of a standard must be established on a solid and long-lasting basis. For this reason, caution must always be applied to all exercised amendments: The investments of the industrial end users and hardware and software control vendors are always expected to be the primary concern. The approach described here represents an appropriate compromise to this concern.

Gray Backgrounds for DCS Operating Displays ?

 In a control room environment, operating displays serve an important role in supporting operator situation awareness and executing actions to prevent and respond to abnormal plant situations. Operator situation awareness involves orienting one’s self to several factors: 

• The presence and location of a disturbance;
• Comprehending the nature of the underlying plant conditions;
• Projecting the impact of the disturbance into the immediate future; and
• Analyzing all these to determine the appropriate course of action. 

The operator display design directly impacts the speed and accuracy of an operator performing these abnormal situation management activities.

The recent evolution of distributed control systems (DCS) to PC-based computer platforms has been accompanied by a significant change in capabilities to present data and information to operators. In particular, the ability to render those first-generation color schematic displays has evolved from the limited use of eight colors with full and half intensity to potentially millions of colors with the ability to manipulate combinations of saturation, hue, and intensity levels. 

The early DCS schematic displays were implemented with these limited color options on black background screens. Moreover, because of the limited colors available, the same color was often used to visually code different data types or status information. For example, the color red might be used to communicate a valve is closed, a pump is stopped, a process parameter is in alarm, and a process line is transferring oxygen.  

From pneumatic panels to CRTs

In parallel to the shift in DCS display technology, the use of black background on CRT screens created an unexpected impact on control room lighting. This unexpected result was in part due to the curvature of the CRT screen itself and in part the phenomena of creating a mirror out of the CRT glass with the extreme contrasts of light on each side of that glass. The result was excessive glare, and the response in almost all control rooms was a migration from bright, well-lit control rooms (with pneumatic control panels) to dark, dimly lit control rooms with multiple CRT based console workstations.

In the mid-90s, the Abnormal Situation Management (ASM) Consortium began studying factors that impacted the ability of operators to prevent and respond to abnormal situations in the plant. One of the conclusions at the time was that the present-day technology supports operators more effectively during steady-state operations than during upset operations. Operator schematic display design was one factor that was identified as needing improvement to support effective operator situation awareness and performance. Consequently, the ASM Consortium began researching human factors in operator display design to identify effective practices based on plant implementations as well as human factors research in academia and other industries. 

This research resulted in the ASM Guidelines publication of the Effective Operator Display Design, and one of the 16 guideline areas was on the effective use of color in operator displays. Within this guideline area there are eight guidelines on the use of color, one of which is the choice of color for display backgrounds. The color-specific ASM guidelines are intended to aid the display designer in selecting a color scheme that enhances the overall operator performance in the control room environment, not how to design an “attractive” display. The color scheme guidelines were created with the understanding that this work context places specific demands on the operator that are not present in contexts such as an office, public facility, or home. For example, operators must maintain continuous alertness over long shifts and monitor for infrequent events that may occur at unknown times. In this context, it is vital the display captures the operator’s attention—particularly when the vigilance performance decrement has been demonstrated across multiple industries for monotonous, low frequency events—when critical data is changing. 

Why gray?

Subsequently, the recommended design practice of using light gray backgrounds on DCS operating displays emerged as a result of several interacting design objectives. A few of these design objectives are:

• Directing the operator’s attention to the most critical information with the least possibility for confusion, slow response, or errors in detection or interpretation;
• Addressing concerns with respect to individuals who might have color vision deficiencies; and
• Reducing glare so ambient light levels are high enough to support both visual acuity for non-display tasks (e.g., reading paper copy) and also biological clock adjustments for the appropriate day or night shift.

To understand the factors that influence design decisions on use of color in operator displays, it is important to understand some basic principles of human sensation and perception. To enhance situation awareness, visual coding techniques are used to draw the operator’s attention to the most critical data and information through enhancing the salience of the associated display elements. An object is more salient than another object if it “stands out,” or grabs one’s attention. In terms of the display design then, this object appears to be in the foreground of the display relative to other objects. 

Manipulating visual attributes

The visual attributes that the designer can manipulate to create different degrees of salience include movement, form, and color. Luminance and color contrast depend on the brightness and color attributes to define the visual distinctiveness of a symbol or object from its immediate background. A minimum level of luminance contrast is necessary for legibility. Manipulating degrees of luminance contrast is effective for managing the viewer’s attention. The most safety-critical or urgent information should stand out the most in the display foreground whereas static and less important data, or information that provides context, such as vessels or display background, should blend more to the background. For operator situation awareness, it’s important to emphasize abnormal states, off-normal conditions, and dynamic data. When the designer is using color to manipulate salience, it is important that the color is used discriminately to code a specific meaning. If red means critical alarm state, then it should not also mean a pump is off (which might be its normal state). Nondiscriminate coding requires the viewer to use additional mental effort and time to exhaustively scan similar colored objects in an operating display and evaluate what the red means in each instantiation on display objects.

To maximize the ability to manipulate salience, the designer needs to consider how the background color supports both effective luminance and color contrast. From a luminance contrast perspective, the designer could choose a white, black, or gray background. A white or black background will provide maximum luminance contrast with dark or light text or objects. Research has shown that the ability to see detail (i.e., visual acuity) is better for dark text on white backgrounds. From a color contrast perspective, the use of a light grayscale background enables the use of a broader range of foreground color choices for manipulating salience than a light colored background such as tan, green, or blue, particularly when one considers the impact on individuals with color vision deficiencies. With a non-gray colored background, certain regions of the foreground color palette fall into the same color spectrum as the background color, reducing the color contrast for normal color-vision individuals and increasing the likelihood of confusion or mistakes for individuals with color vision deficiencies. 

 Why not white or black?

So why not use a white background display instead of gray? One reason is that the background display color in combination with the ambient light level of the control room can impact the probability of eye strain and fatigue as well as visual acuity. When someone is looking at a bright display in a dark room or a dark display in a bright room, the eyes have to make an adaption to the change in luminance as they move about the room and at the displays. With the successive viewing of light and dark sources over the period of a 12-hour shift, operators may experience eye strain and fatigue.

From the operators’ perspective, the background luminance of their displays will be the main determinant of their eye adaptation level. Hence, keeping the contrast between ambient lighting in the control room and background display luminance to a minimum can improve eye comfort. In addition, visual acuity has been demonstrated to be better when the surrounding or ambient luminance is equal to the display luminance. Hence, the recommendation of a light display background is coupled to the recommendation for high ambient lighting in the control room. 

A key consideration for deciding on ambient control room light levels is their impact on operator alertness. Low alertness levels are shown to reduce operator performance. Long work shifts (typically 12 hours) coupled with a rotating shift schedule presents significant challenges to operators in maintaining an effective alertness level due to the impact on their biological clock. Working in a dark control room exacerbates the challenge of maintaining alertness because it causes a physiological reaction that facilitates sleeping. Hence, bright, well-lit control rooms can improve operator alertness levels and subsequent performance.

In conclusion, the combination of design factors that impact operator situation awareness, alertness, eye strain, and fatigue led to the general recommendation to use a light-colored background on operating displays in a well-lit control room. Secondly, for a broader choice of colors that provide an effective contrast against the display background color, most operator display designers end up choosing gray as the background color as opposed to tan, green, or blue. In the end, the ASM Consortium recommends gray backgrounds due to the positive impact on operator performance rather than on operator preference for aesthetically pleasing colored displays. Moreover, the ASM Consortium does NOT recommend only using grayscale in display design but to use an effective color scheme to establish the relative importance of information and subsequently communicate distinctive meaning at a glance.  However, display designers must realize that color usage is only one of several considerations when designing an effective operator display. The ASM Consortium guidelines provide a comprehensive set of recommendations for ensuring the operator display maximizes human performance when dealing with abnormal situations.

Additional reading:

Bullemer, P.T., Reising, D.C., Burns, C., Hajdukiewicz, J., and Andrzejewski, J. (2008). Effective operator display design. ASM Consortium Guidelines Book. Minneapolis, MN: ASM Consortium.

Arend, L., Logan, A., and Havin, G. (2011). Using color in information displays graphics. NASA Ames Research Center, http://colorusage.arc.nasa.gov.

Panel on Impact of Video Viewing on Vision of Workers. (1983). Video Displays, Work, and Vision. Washington, DC: National Academic Press.