Tag Archives: Troubleshooting

VFD’s and Long Motor Leads

VFD, ,

Recently I came across an application where multiple motors were failing at a single site. This facility utilized VFDs to control several rooftop AC induction motors. The repeated motor failures raised concerns about the possible causes, prompting a deeper investigation into the relationship between long motor leads, motor failures, and VFDs.

Long Motor Leads + VFD’s

The use of long motor leads can cause issues in VFD-driven motors. Voltage reflections and voltage magnification can occur, leading to voltage spikes that can exceed the motor winding insulation capabilities. These spikes, if left unaddressed, may result in premature motor failure due to insulation degradation.

VFD Strategies for Long Motor Leads

 

  1. Adjusting Carrier Frequency: Reducing the carrier frequency of the VFD can help minimize the impact of voltage reflections and the risk of motor failure due to long motor leads. However, this may result in increased audible noise and reduced motor efficiency, so finding an optimal balance is crucial.
  2. Motor Chokes: Installing motor chokes, also known as output reactors can help mitigate voltage reflection and reduce the risk of insulation breakdown.
  3. Motor Insulation Ratings: Using motors with higher insulation ratings, such as those designed specifically for use with VFDs, can help protect against voltage spikes and reduce the risk of motor failure.
  4. Proper Grounding: Ensuring proper grounding practices can help minimize bearing currents and their associated motor failures. While this is not directly related to motor lead length, longer lead lengths can contribute to conditions that cause bearing currents. Some examples of ‘fluting’ and bearing issues here: https://empoweringpumps.com/est-aegis-protect-motors-from-variable-frequency-drive-induced-bearing-damage/
  5. Cable Shielding: Using shielded motor cables can help reduce electromagnetic interference and protect the motor from high-frequency voltage pulses.

For reference, the formula for the reflection coefficient is below. The greater the mismatch, the greater the voltage amplification factor.

                                   R = (Z_load – Z_source) / (Z_load + Z_source)

                                   where:

                                  R represents the reflection coefficient

                                  Z_load is the impedance of the load (in this case, the motor)

                                  Z_source is the impedance of the source (in this case, the VFD)

The formula for the voltage amplification factor:

                                V_max = 1 + |R|

      where:

                            V_max represents the maximum voltage on the line

                           |R| is the absolute value of the reflection coefficient

Another important note is in situations where there are multiple motors driven by a single VFD, the length of cable to each VFD is summed up as the total motor cable length calculation.

Motor Issues Not Caused by the VFD

There are other motor failure scenarios that get misattributed to VFD’s. These may continue occurring even with mitigation techniques above. As such, it’s important to rule these out beforehand. Some common examples:

  1. Environmental Factors: Exposure to harsh environmental conditions, such as extreme temperatures, humidity, or contaminants, can cause motor failures. These issues may be mistakenly linked to VFDs when they are actually the result of inadequate motor protection or improper maintenance practices.
  2. Mechanical Failures: Mechanical issues, such as misalignment, imbalance, or excessive vibration, can lead to motor failures. These problems may be incorrectly attributed to VFDs when they are actually caused by issues within the mechanical system, such as worn-out bearings, loose components, or improper installation.
  3. Overloading: Overloading a motor, either by exceeding its rated capacity or by running it for extended periods at high loads, can result in overheating and failure. This type of failure might be incorrectly attributed to VFDs when it is actually due to improper motor sizing or incorrect application.
  4. Electrical Issues: Motor failures caused by electrical issues, such as short circuits, phase imbalances, or power quality problems, can also be mistaken for VFD-related failures. These issues may stem from faulty wiring, improper grounding, or voltage fluctuations in the electrical supply.
  5. Inadequate Lubrication: Insufficient or improper lubrication can lead to bearing wear and premature motor failure. This type of failure may be misattributed to VFD-related bearing currents when it is actually caused by poor maintenance practices or the use of inappropriate lubricants.
  6. Design or Manufacturing Defects: Motors with inherent design or manufacturing defects may experience premature failure. These failures can be incorrectly linked to VFDs when they are actually the result of flaws in the motor’s construction or assembly.

 

Conclusion:

While long motor leads can pose challenges for VFD-driven systems, by understanding the risks, adjusting VFD setup and settings, and taking appropriate preventative measures, it is possible to mitigate the risk of motor failures. Additionally, recognizing motor failures that are commonly misattributed to VFDs can help ensure accurate diagnosis and effective solutions. By incorporating proper grounding, choosing the right motor insulation ratings, and utilizing motor chokes and cable shielding, you can enhance the performance of your VFD-controlled moto

Share

PLC Program Debugging Checklist: 5 Things to do to correct errors during PLC Program development

PAC, PLC, Programming,

 

So, you’re programing in a PLC platform that is new to you. The functions, tools and syntax may be different from what you are used to. As you get acquainted with them, there are probably going to be errors showing up in the message list when a build or compile is performed. The following are 5 things to do to debug or correct these errors when developing a PLC program.

 

Checklist item 1: Compile as you go (don’t wait until the end) and check the messages

a. About compiling often: Nobel Prize winner Daniel Kahneman in his book ‘Thinking, Fast and Slow’ states a correlation between the ability to build expertise on a topic and the speed and quality of feedback during the process of learning. The inference of this in building PLC programs, specifically in an environment you are new to, is:

  • Compile or build the program often
  • Decipher the compile errors and messages accurately.

Some programs or programming environments are going to take longer to compile so this habit is dependent on the environment too.

b. The second part about deciphering the error message accurately is highly reliant on the environment itself. For instance, I am working in an IEC 61131-3 environment called SoMachine HVAC. The error message said ‘Token not found’ and pointed to an inexistent line number in the POU. After using Step 2 below, it turned out that one of the variables had a period/dot (.) in front of it which is acceptable in the CODESYS environment but not in the new environment. Removed the period/dot and the error message went away.

About checking the messages, observe if there are root cause messages that are effecting other error conditions. In CODESYS for instance, addressing the errors at the top of the error message list often results in the solving of multiple other errors that are lower in the list.

 

Checklist item 2: Check the help files and any example programs available

Some environments may have  a manual. Some may have a good Help section. On either one of those, browse through the contents of the manual and Help files. When a problem arises, it may come in handy.

Another good reference is an example program. Trying to figure out how a read operation is performed over a comms network? Or maybe just the usage of a simple CASE structure sequence? Having one good written up program helps and can serve as a ‘go to’ program. When starting in a new environment, ask the vendor for some example code and programs.

 

Checklist item 3: Test only the suspect function, in a separate POU.

 

The idea here is to test the function and its utilization method. If you are using the function wrongly then this step will pick that up. Break the function down to the arguments that are fed to it. Check if any one of the arguments are of incorrect type of using wrong syntax. The ideal case is if the compiler picks up the error and tells you what is wrong but that is not always the case.

 

Checklist item 4: Comment out sections of the program and check if the errors persists.

 

As is common in tackling any engineering feat, ‘divide and conquer’. Comment out sections of the code and perform compiles systematically. Start with the section you suspect to be the root cause and then expand from there.

 

A note about the psychology of debugging; sometimes it is easy to blame the problem on the programming environment or a vendor. You might be telling yourself ‘This programming environment is buggy’ or ‘It’s not user friendly’. Try to quash this, have some faith and be bullish about solving the problem. This has helped me tackle problems much quicker rather than going back and forth with tech support or giving up only to find a simple solution I had overlooked.

 

 

Checklist item 5: Build your go to resource list … and Google away

 

Document your findings somewhere. Preferably somewhere searchable. This step takes time but will save you time later. Also, when someone comes to you for help, you will have something to give them – which helps me since I work for a vendor.

As stated above, collect examples from the vendor.  I collect examples from colleagues, previous projects, development team…

Vendors may also have an online FAQ list, forum or wiki page. Get to know those resources.

Another resource maybe online forums like PLCTalk. For CODESYS, check out the CODESYS forum.

 

Hope this helps as a debug checklist. If there are any other methods out there, please add them to the comments section below. Given the thousands of hours controls engineers and PLC programmers spend debugging, there is probably a part 2 that needs to happen on this topic.

 

 

Share

Importance of Modbus Polarization Resistors

PLC, VFD,

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