All posts by Drives & Systems

Choosing between variable frequency drives (VFD) and soft starts

 

Soft starts usually vary voltage with SCR'sSoft starts usually vary voltage with SCR’s

A key difference between drives and soft starts:

Drives can continuously vary the frequency and voltage supplied to the motor. Soft starts vary only the voltage supplied to the motor, and usually only when ramping a motor up and down.

What does this mean?

Soft starts may vary the speed of the motor during startup and ramp down but this is done by reducing the motor voltage. On this note, the soft start is also called a reduced voltage starter. Drives do the same but also have the option to control motor speed by varying the voltage frequency instead of the voltage.  Motor speed is directly related to its supply voltage frequency.

 

Inherently, a drive or a soft start reduces the inrush current that every motor is subject to when starting across the line. From this perspective, either a drive or a soft start will probably prolong the life of a motor -specifically if compared to an across the line starter. This is a general statement and like most general statements, there are some conditions.  Specifically for drives, this general statement usually applies to inverter duty rated motors which can withstand the continuous high frequency switching (PWM) of the drive. Otherwise, there is a risk in applying a drive to a motor. It might heat up the winding insulation and ultimately break it down.

 

The soft start topology is usually a single stage SCR based switching scheme with a bypass. The bypass takes over  for operation at full speed (diagram above). The SCR’s fire for gradually longer parts of the AC voltage cycle until the entire AC wave is passed through to the motor. At this point, operation is handed over to a bypass.

 

VFD's vary voltage and frequency with the 3 stage design.VFD’s vary voltage and frequency with the 3 stage design.

 

The drive topology has 3 stages (diagram above), with a rectifier taking in line supply and then a DC bus capacitor that stores and buffers the DC energy within the . The final stage is the inverter which is usually made up of IGBT’s at the motor supply side of the drive. The IGBT’s can continuously operate at varied gating frequencies to produce a variable frequency supply to the motor.

When choosing between drives and soft starts, some key differences to consider are:

Key differentiators

VFD Soft Start Meaning
Speed Variability Continuously variable speed throughout operation Initial ramp up of voltage/speed. Subsequently pegged to line frequency. Drives can save energy if the load does not need to run at full speed. Soft starts do not save energy in full speed operation. Then again, some applications are designed to operate in full speed operation. These loads will not benefit from a drive from this perspective.
Control features More control features: Features that take effect during operation at regulated speeds. Less control features as speed is not regulated besides during startup and ramp down.
Application Torque Constant torque supported- i.e. high torque at low speed.

Examples: Screw compressors, conveyors.

Variable torque applications- lower torque at low speed.

Examples: Centrifugal pumps, fans.

Some loads require a high amount of torque when starting. A VFD is applied on these applications
Main features Reduce inrush and continuously vary frequency and motor speed. Energy savings during operation. Reduce initial inrush. Energy savings during ramps, no energy savings after ramp up and ramp down.

 

 

 

Share

CODESYS Visualization (and WebVisualization)

A CODESYS Visualization or Viz, is a way to embed a graphical interface into a PLC program. Interfacing with the PLC programs visually allows for quicker troubleshooting among other benefits. Further to that WebVisualizations publish a CODESYS visualization in HTML5. This enables user access to a PLC visualizations via a web browser.

Several examples of Visualizations and WebVisualizations exist online. Visualization and WebVisualization screens are created with drag and drop objects which are configured instead of coded. This simplifies screen development instead of having to build Java or HTML based objects for web accessible screens on the PLC.

The collection of YouTube based Visualizations highlighted below showcase the possibilities with the various screen objects across various applications – some industrial and some exemplar/illustrative.

The first example  is of an elevator application built in CODESYS. Credit to donkeykowng on creating this for a school project.

The next example is of an industrial mixing process with multiple tanks with levels updated dynamically. Credit to tweektweak23.

The next two credited to Kye-Hun Park .
Tetris . This visulization was built in SoMachine 4.1 which uses CODESYS 3.5
Snake game
 
Combination of  2D conveying and tank on a filling application.
CNC application courtesy of Martin van rijn
Another tank level application. Credit to Huseyin Gevrek
Material handling example with a couple of axis of a pick and place and a conveyor.
Credit to binyam .yo
More recent update of Codesys includes support for multi-touch. (from CoDeSysMotion YouTube page)
 A key benefit of a visualization is that it allows for parts of the PLC program to be graphically represented and viewed without the PLC programming software. This is given that the programmer or designer of the system designs and embed appropriate visualizations to represent the system. Being able to pull up a graphical representation of the system on a PC/tablet/phone browser allows for preliminary  troubleshooting without too many people having to have the programming software license . If the problem  is beyond wiring , mechanical or I/O issues , then someone with the programming software can be dispatched.

 

Share

Importance of Modbus Polarization Resistors

Modbus has been around for several decades and is widely implemented.  There are several elements of starting up a system with Modbus serial networks that usually get repeated. These include address, baud rate and parity. One element which does not get too much mention is the Modbus polarization resistors which can play a major role.

What does the polarization resistor do?

The detection margin requirement across the B and A signals is usually only about 200mV. With polarization resistors, the actual margin is ‘widened’ specifically when the signal drivers are not ‘driving’ thus allowing for better noise tolerance as well. This is especially true with networks that have variable speed/frequency drives  with high frequency switching being a large source of noise. The resistors are known as pull-up and pull-down resistors as they tie the B signal up to the 5V rail and the  A signal down to 0V.

On a recent startup, the PLC and HMI program was downloaded and the control program was being tested when the system started to act erratically. Closer observations revealed that the Modbus serial communications with the drive was sporadically dropping out, specifically when the drive was running the motor. All read values were becoming zeroes when this happened.

After trying several things, the polarization resistors solved the problem.

 

PolarizationResistorsThings to note about polarization resistors:

  1. Applied only once on each network. PLC’s may have this as an optional item in the Modbus port configuration. Slave devices usually do not have it though many manufacturers will advise on how to apply if when needed.
  2. The presence of polarization resistors could reduce the number of slaves that can be had on the network, specifically if a lower pull-up or pull-down resistance is used. This and many other important points about Modbus is covered in the specification at Modbus.org.
  3. What size resistors to use? The Modbus standard specification calls for resistance between 450 ohms and 650 ohms. Manufacturers usually have a guide. A good example to calculate it out is noted on page 11 of this document.

Polarization resistors are one factor to note in troubleshooting Modbus serial networks, others include proper grounding practices and proper usage of terminating resistors.

Share

CODESYS Array Sorting for PLC programs

 

BubbleSort

 

Sorting functions have increasing use in PLC programs thanks to more powerful processors and more memory. One example is sorting an array of motor runtimes from lowest runtime to highest runtime so that the next run cycle will utilize the motor with the lowest runtime first. This example is useful for pump applications and is referred to in the post about pointers in CODESYS.

To implement a pump runtime based sort, other elements in CODESYS such as DUT’s( user defined data types)  and structures could probably be useful. The reason is that the result of the sorting function is to know which pump to run next. This can be done by having two dimensions in the array, a Pump ID/Number along with the Pump Runtime. For the purpose of simplicity, only a simply bubble sort with two FOR loops is shown below, the DUT approach is not shown here.

A simple bubble sort can be implemented in CODESYS with the following code. Instead of sorting the actual array, this example sorts an array of pointers ( dereferenced to get the actual values from the pointers). This way the original array data locations do not need to be altered. Not altering the original array locations is a good thing because in some cases, these array locations may be hardcoded to physical inputs.

(*Prior to implementing the sort, an array if pointers is loaded *)

FOR l:=0 TO n BY 1 DO

pointToArrayElement[l]:=ADR(TestArray[l]);

END_FOR

(*Bubble sort- The value of n should be equivalent to the last array element*)

FOR i:=0 TO n BY 1 DO 

                                                (* The second FOR loop compares two elements of the array at a time and sorts*)

FOR j:=0 TO n-1 BY 1 DO

IF(pointToArrayElement[j]^>pointToArrayElement[j+1]^) THEN

temp := pointToArrayElement[j+1];

pointToArrayElement[j+1] := pointToArrayElement[j];

pointToArrayElement[j] := temp;

END_IF

END_FOR

END_FOR

 

The variables used in this example:

 

VAR

TestArray: ARRAY [0..4] OF Pump;
TestArrayPointers: ARRAY [0..4] OF POINTER TO INT;

i: INT;
n: INT;
j: INT;

l: INT;
temp: pointer to INT;
pointToArrayElement: ARRAY OF POINTER TO INT;
END_VAR

 

Other notables: If this is implemented in a function or even in a program , the integers used in the FOR loop iteration need to be reset after the sorting is complete and it would be required to sequence through the loading of the array of pointers, sorting  and resetting of the iterative integers possibly using a CASE structure  or some IF statements.

 

 

 

Share

PLC Programming Patterns- The Debounced Threshold/Limit

Patterns in PLC Programming: The threshold + timer function – Debounced Threshold

PLC programs are frequently made up of the same sets of functions or patterns of logic. These patterns perform commonly required control routines. Examples include threshold detection for alarm purposes, input/output mapping and scaling functions, to name a few. These combination of functions make up re-usable patterns or function sets that form the building blocks of a PLC program.

Repeated usage of some functions in a PLC programming environment holds true to the universal 80/20 rule ;20% of the functions available in a programming environment( such as timers and logic functions) would probably be used to build 80% of PLC programs.

The debounced alarm/threshold pattern is one of these commonly required PLC programming patterns. This pattern is probably better written in ladder diagram   (instead of any of the other 61131-3 languages), for two reasons:

  • Maintenance personnel will be able to view the status of the process/monitored variable, associated timer and output all in the same place
  • It can be programmed in 2 rungs of ladder compared to more than 10 lines of code.

The ladder diagram version could look something like this:

Alarm ACTIVE
DebouncedThreshold_LD_ALARMAutoManualReset

Note: An Auto/Manual Reset Provision is built into the Alarm Reset Timer rung.

Alarm NOT ACTIVE

DebouncedThreshold_LD

The following pattern is the debounce pattern for detecting limit breaches along with a timer, written in Structured Text for the CODESYS environment. As described above, the structured text version takes more space and possibly looks more intimidating specifically to someone who is used to the ladder environment.

CODESYS-LimitThresholdScreenCap

The plain text version of the structured text version is attached below:

PROGRAM DeBounced_Limit

VAR

irProcessValue : REAL; (*Process value scaled from analog input signal*)

rProcessLowLimit : REAL; (*User defined process value low limit alarm threshold*)

qxLowLimitAlarm : BOOL;(*Low limit alarm bit*)

LowLimitAlarmTimer : TON; (*Process value low limit alarm trigger debounce timer*)

LowLimitAlarmResetTimer : TON; (*Process value low limit alarm reset debounce timer*)

LowLimitDebounceT : TIME; (*Process value low limit alarm trigger debounce time*)

LowLimitResetDebounceT : TIME; (*Process value low limit alarm reset debounce time*)

xAutoReset : BOOL;(*User enabled alarm auto reset function*)

ixUserReset : BOOL;(*User triggered alarm reset function for manual reset*)

END_VAR

(*If value is lower than low limit, start timer, else reset timer*)

IF irProcessValue < rProcessLowLimit THEN

LowLimitAlarmTimer(in:=TRUE, PT:=LowLimitDebounceT);

ELSE

LowLimitAlarmTimer(in:=FALSE);

END_IF

(*If timer lapses, trigger alarm bit*)

IF LowLimitAlarmTimer.Q THEN

qxLowLimitAlarm:=TRUE;

END_IF

(*If value is higher than low limit, start alarm reset timer, else reset debounce timer*)

IF irProcessValue > rProcessLowLimit THEN

LowLimitAlarmResetTimer(in:=TRUE, PT:=LowLimitResetDebounceT);

ELSE

LowLimitAlarmResetTimer(in:=FALSE);

END_IF

(*If timer lapses, and system permits auto-reset, reset alarm bit*)

(*If the system does not permit auto-reset, add user invoked reset bit here*)

IF LowLimitAlarmResetTimer.Q AND (xAutoReset OR ixUserReset) THEN

qxLowLimitAlarm:=FALSE;

END_IF

Share

CODESYS Pointers and Dereferencing

Pointers and Arrays in CODESYS

The CODESYS language supports the usage of pointers which is essentially a variable that stores the location of another variable or data point instead of its value. The actual value of a variable that a pointer points to can be retrieved by dereferencing the pointer.

 

What could it be used for?

       1.Storing the location of the variable saves space specifically when pointing to large                 data points or structures.

  1. Pointers allow for sorting and re-arrangement of data sequences without actually changing the location of the original data points. To characterize in a diagram:

Pointers and Arrays Diagram

  1. Going down the path of object oriented programming in PLC’s/PAC’s, this supports abstraction by separating the usage, manipulation and parts of an object from the original object itself. This helps reduce the PLC code required to handle every scenario and also helps in situation where the original object can not be manipulated because its hardcoded to an input ( for example).

 

Example:

 

Let’s say the array of data on the left side of the diagram above is read (as inputs) from a set of 4 drives controlling 4 pumps. From top of the array to the bottom Array location 0 would be for Pump 1 , location 1 for Pump 2 …..location 4 for Pump 4.

 

If the data is each of the pumps runtime, the pointers to the runtime allow for it to be sorted and stored in the pointer of arrays without changing the order of the original array which is important, as the original array of runtime data may be hardcoded to the actual input or read values from the drives.

 

Secondly, when the decision is made to call a pump to run, the same mechanism of pointers and arrays and de-referencing can be used to point to the command word of each of the pumps on a communication bus.

The end result is the amount of code required in determining which of the pumps to run is reduced.

Pump Example Pointers and Arrays

What does the syntax look like in CODESYS?

To create a pointer:

The address operator or ADR is used.

Let’s say the variables are:

 

PROGRAM PLC_PRG

VAR

j: INT;

k:INT;

pointToJ: POINTER TO INT;

END_VAR

The pointer assignment would be:

 Pointer

in plain text:

pointToJ:=ADR( j);

Note: ADR is a CODESYS operator and not an operator prescribed in IEC61131-3.

 

To de-reference a pointer:

The ^ operator is used to de-reference pointers.

Example:

in plain text:

k:=pointToJ^;

This would yield the value of integer j.

SimulatedPointerDeReferencing

 

Share

HMI Design Guidelines for every project

After building two user interfaces this year and having to formulate and review the rules for developing an effective set of screens each time, this is a list of seven items created from experience, client feedback and research.

7 HMI Design Guidelines

1. Do not use black or white for background. It appears that this would bring about good contrast and highlight objects onscreen but to the contrary, it succumbs to glare in many lighting conditions including sunlight and fluorescent lighting.

2. Low contrast general themes are better in industrial user interfaces for the following reasons: 1- It helps highlight situations that require awareness, 2- It’s not too eye catching as an industrial control system should be. Captivating graphics may steal from the actual intent.

3. Use graphs and trend information where possible. Visual aspects of monitored variables allowsfor easier troubleshooting. Historic view of what the variable has done whether a few minutes ago or a few hours ago helps operators with decision making. A trend can also captures a relative view of the current state with respect to limits and also in relation to other variables.

4. Articulate situations that are beyond acceptable or normal operating regions using bar graphs and colors( red, yellow green). This supports the notion of providing a relative view of the status of a process variable or condition.

5. Do not use too many elements that do not carry data significance. Example: An elaborate drawing of a plant or process with only 4 or 5 actual data fields may serve as a distraction. The idea is not to amaze users/operators/viewers with the graphics but to provide information and allow for efficient and optimal control.

6. Consider replacing color based information with shapes- helps with color blindness and confusion on the meaning of colors. Example: Does RED infer push to stop or currently stopped. Does green mean go or push to go?

7. Spacing between user input fields- avoid the proverbial ‘fat finger’. Example :Placing two input fields  together can cause  errors in data entry. Consider placing a label between input fields.

Share

Auto tuning VFD’s

 

What is auto-tuning to a VFD?

Auto tuning a VFD is a process by which a drive measures the impedance of a motor for the purpose adjusting the motor control algorithm. The measured value may be matched to known impedance for a given motor size and used in determining voltage and current relationships at different speeds. Ultimately, this allows for more effective  driving of a motor load as well as better speed regulation specifically when running without feedback ( open loop).

When not to auto-tune?

    1. Auto-tunes are generally to be performed when the motor is cold. Auto-tuning with a hot motor may result in a variance in impedance which will subsequently cause the execution of a motor control algorithm which does not accurately match the true motor impedance.
    2. When multiple motors are connected, an auto-tune will result in the reading of multiple motor impedances connected in parallel. Some auto-tune functions match impedance readings to known typical motor impedance values ( for instance a typical NEMA B motor). As such, the reading of multiple motor impedances in parallel can not be matched to a known motor impedance value or may match a different type of motor. This results in an unsuccessful auto-tune which may be signified by a higher than usual noise levels.
Share

Reactors and Filters in VFD Applications

Discussion on filters when associated with drives can include  line reactors, matrix filters and sinus filters among others. The filters can be on the line side of the drive for harmonic mitigation or transient protection purposes. On the load side, reactors may be used for reflected wave mitigation( caused by long motor lead lengths for example) or sinus filtering which is to filter out higher frequency components of the output of the drive to the motor.

A reactor is essentially an inductor which acts to ‘smoothen’ out the voltage on the line/load . These are typically applied in variants of 3% or 5% of the line impedance, thus reducing the voltage by 3% or 5%. Going from a reactors, other forms  of harmonic mitigation may involve  combination of reactors and capacitors.

The following manufacturers of power quality and filtering equipment have useful resources on the various techniques of filtering and their application in improving power quality with drives:

MTE : http://www.mtecorp.com/

TCI: http://www.transcoil.com/Support/Documentlibrary.htm

 

UPDATE: Another one that I had heard of but never used.

MIRUS : http://www.mirusinternational.com

Some good technical papers in the Downloads section including an interesting paper comparing Active Front End’s(AFE’s) to a regular 6 pulse rectifier front end and a filter.

Share