Understanding the confusing terminology of brushless DC (BLDC) motors

This is a condensed discussion of the terminology of DC electric motors, using object design’s class terminology.

The technology of motors has a long history.   Terminology used over that history is not always consistent.  Even at a moment in time, different sources may use differing terminology.

No warranty: this may be incorrect, and it is incomplete.

Brushed versus brushless DC motors

BrushedCommutated and BrushlessCommutated are subclasses of the class Commutated.

Brushed motors: mechanical commutation.

Brushless motors: electronic commutation.

Brushless motors are more reliable (have longer life) because electronics last longer than mechanical, generally speaking.  For example, the brushes may be copper fingers rubbing against copper rings.  Rubbing wears the fingers away.  Also, electrical current sparking across the gap between the fingers and the commutation ring eats them away.

Stepping motors versus brushless DC motors

SteppingBrushless and ContinuouslyDrivenBrushless are subclasses of BrushlessCommutated.

The distinction is one of purpose and control.  Otherwise, instances of the two classes may  have similar mechanical design.

Stepping:

• purpose is precise angle of rotation
• control is a finite sequence of steps

Brushless DC:

• purpose is continuous rotation
• control is a continuing sequence of steps

Magnetic poles

A single magnet has two poles, North and South.  But an arrangement of many magnets is also said to have many poles.  For example, a ring of four magnets, when viewed either from the inside or outside of the ring, can be said to have four poles.

The Poles class gives a Geometry.  Poles is a mixin behaviour of a CompoundMagnet (which includes a single magnet.)

Magnetic field concentration

Some materials, such as iron, concentrate the field of a magnet.  A particular configuration of such material may be called an armature or a yoke.   The concentrations it produces may also be called poles, although it might be better to call them lobes.

A coil (electromagnetic) may produce many poles (lobes) because of an armature.

Poles is also a mixin behaviour of a Compound of a CompoundMagnet and an Armature.

Axially wound versus radially wound

DC motors have coils, part of electromagnets.

The coils have a certain geometrical relation to the axis of rotation of the motor:

• Axially wound: coil wound around the axis of the motor.  Line of axis of coil is coincident with line axis of rotation of the motor.
• Radially wound: Line of axis of coil is orthogonal to line axis of rotation of the motor.

An axial coil may produce a radial pole.  It is non-intuitive that an axially wound motor would work, except that an armature concentrates the magnetic field of the coil into poles (lobes) that are NOT axial to the motor, but orthogonal (radial) to it.

In other words, the Poles behaviour of a compound of a magnet and armature need NOT delegate: the combination of magnet and armature may produce a different geometry than either of the parts.

Unipolar versus Bipolar

These terms describe a sequence of energizing coils.  They both refer to a motor having two coils (and any number of lobes, due to an armature!).  These terms describe the control or driving of a motor, not the mechanical design, nor the configuration of magnetic poles.

• unipolar: only one coil energized at a time
• bipolar: two coils may be energized at the same time

A bipolar driven motor is denser (produces more torque per mass) because the coils are energized more often.  In other words, at any given time, a unipolar driven motor has about half its weight (one coil out of two) that is dead weight because it is not energized.  A bipolar driven motor is generally 1.4 times as powerful (torque) as a unipolar motor of the same weight.

Windings versus coils versus bobbins

(These definitions may not be correct to all readers.)

A coil is one or many, concentric,  circular turns of wire.  Coils may be wound on a bobbin, which holds it in place.  Coils may also be wound around an armature.

Two coils in series makes one winding.  For example, the coils may be on opposite sides of the motor, but part of the same winding.

Two coils in series but with a third wire (a tap in the middle of  the long wire) from the junction between them, makes two windings.

A common example

For example, a common type of brushless PC fan motor.

It has one bobbin, axial.  Two wires are wrapped axially around the bobbin.  At first glance, it looks like one coil, but it has four wire ends.  Thus it is two coils and two windings.

The motor is driven unipolar.  In a unipolar driving circuit, two wire ends, one from each winding, are at the same electrical potential, tied together.  Thus you could say what is on the bobbin is a tapped wire.

The electronic commutation control circuitry is on a circuit board at one end of the motor.  It drives the motor continuously whenever power is supplied.  (Different circuitry could just as well drive it as a stepping motor, although it might not be precise as another design.)

The motor has a Y-shaped yoke or armature at each end.  The Y-shaped yokes are not aligned with each other, not at the same angular position.  These shape the magnetic fields of the windings into many lobes.  (Other motors have toothed cups to shape lobes.)

The motor has permanent magnets in a ring outside the windings.  The material of the magnets is one topological donut shape (flattened) of refrigerator magnet composition.  The donut has many magnets established in it, that is, the donut has many poles.

Referencing Python projects in Eclipse and PyDev

About this post

Suppose you are:

• programming in Python
• using the Eclipse IDE
• with the PyDev plugin
• and have many projects that are subsystems of a larger app or system.

This tells you how to join your subsystem projects using Eclipse ‘references’.

How to

I will call the two projects the ‘referring project’ (say an app) and the ‘referenced project’ (say a subsystem.)  By subsystem I mean a Python package that more or less stands alone and has a well defined API (that you or others might reuse in a larger project.)

To reference one project from another in Eclipse when using the PyDev perspective :

• click RMB (right mouse button) on the referring project name in ‘PyDev Package Explorer’ panel.  A pop-up menu appears.
• choose ‘Properties’ (near the bottom).  A ‘Properties’ dialog appears.
• click LMB on ‘Project References’ in the list in the left panel of the dialog (the list is tree structured.)  A list of checkboxes appears in the right panel of the dialog.
• Click on the project you want to reference (another PyDev project or maybe a C project if  it is a Python extension?)
• Click on the OK button

Now when you run the referring project from within Eclipse, PyDev will set the PYTHONPATH system variable so that the referring project can import the referenced project.  (When you later install the referring project somewhere else, you will also probably include the referenced project in the ‘installation package’, and install both in the standard place.)

Caveat: subsystem projects that are not Python packages

The above works if the referenced project is a Python package (has an __init__.py file in the root directory.)  Suppose however, you have structured your referenced Python project tree like a C project (with a bin and source directory), with only the source directory being a Python package, e.g. with a path  like ‘myUsefulProject/myUsefulPackage.’  Then the above doesn’t work (PyDev only makes the PYTHONPATH include myUsefulProject but not myUsefulPackage.)  Instead of using references, you can set up the PyDev PYTHONPATH yourself:

• click RMB (right mouse button) on the referring project name in ‘PyDev Package Explorer’ panel.  A pop-up menu appears.
• choose ‘Properties’ (near the bottom).  A ‘Properties’ dialog appears.
• click LMB on ‘PyDev PYTHONPATH’ in the list in the left panel of the dialog.  A set of tabs appears in the right panel.
• choose the ‘External Libraries’ tab.  The right panel changes.
• click the ‘Add source folder’ button
• navigate the file browser to the subfolder of the referenced project that is a package (e.g. /home/<yourname>/git/myUsefulProject/myUsefulPackage)
• click the OK button, and again

Note the warning “Changes in external libraries are not monitored, so, the ‘Force restore internal info’ should be used if an external library changes”.   This means, that as a syntax checker, PyDev does not monitor changes to external libraries.   So for example, if you delete a method from an external  library, PyDev will not show an error in a referencing project (at the source code line where it calls the deleted method.)   But when you run the referencing project, Python itself will find the error. (The difference is PyDev’s static checking versus Python’s dynamic checking.)

(As a piece of technical writing, that warning is poor.  It includes three passive verbs.  I would rewrite it “PyDev does not check for errors in referencing projects when you change referenced external libraries.  You should choose ‘Update PyDev’s syntax checking’ when you change the dictionary of external libraries.’)

Linking Python projects in Eclipse with PyDev

This is deprecated:  it still works, but see my later post about referencing Eclipse PyDev projects.

Suppose you have two Python projects in the Eclipse IDE and you are using the PyDev plugin for Eclipse.  You want to import one project from another.

One way to do it:

1. in first project, in Eclipse, created a linked folder to the source subfolder of the second project, containing a module named foo.
2. in the first project, in Eclipse, add the linked folder to Properties> PyDev PYTHON_PATH> Source folders
3. in the first project, in some file, use “from foo import FooClass”

This is what your Eclipse directory tree looks like (in the PyDev Package Explorer frame):

FirstProject 
   > packageFoo  
   packageBar     
       __init__.py
       bar.py
SecondProject  
   packageFoo
     __init__.py
     foo.py

Here, the indentation level shows the tree structure, and the “>” is the icon that Eclipse uses to indicate a linked folder. In bar.py, you find the code:

from foo import FooClass

Note that you import module foo, not packageFoo.foo (since packageFoo is in PYTHON_PATH, its modules can be imported.)

Note that the packages ARE packages because they include a file named __init__.py.  That file typically is empty.

Referencing to the real world in zooming user interfaces

An application with zooming lets a user zoom in and out.  (” zooming user interface”  means more than that, it means the whole desktop experience is flavored by zooming.)  Many applications use zooming.  Some applications need a reference to the real world, so the user knows the real world scale of what they are zooming.  This post is about design issues, especially for drawing apps.

Words related to “reference to the real world” are “dimensioning”, and “standard”.  Here the pertinent meaning of standard is “an object that under specified conditions defines, represents, or records the magnitude of a unit”  e.g. the meter stick in a national bureau of standards.  Here “reference to the real world” means:

• “a displayed object that represents a standard”,
• OR “displayed objects that give dimensions.”

For example, a chronology app, that shows a timeline, may reference to the real world by displaying tick objects on the timeline, with year labels on the ticks.  Then a user knows how much time a segment of the timeline represents.

Some zooming applications don’t need references to the real world.  For example, a presentation app such as Prezi may not need references to the real world, because the things that are being zoomed are just abstract ideas (or images of the real world, with inherent reference to the real world.)

Drawing applications usually need references to the real world:

1. when the thing being drawn is a real world object
2. when the user may control the default scale of the drawing (when displayed to others.)

A common design is to display a rectangle for the paper size.  Inkscape uses this design.  As the user zooms in or out, the rectangle for the paper size grows and shrinks, and the user knows the real world scale of the drawing (when it is printed.)

It is not enough to know the zoom level percent, which is also commonly displayed.  Without an explicitly displayed reference to the real world, the user’s only reference is to pixels.  Pixels are not the same real world size on all devices.  That is, pixels are not really units, in the sense that they have a known standard.  (But there is a limited range of pixel sizes among most common display devices, excepting roadside digital billboards, so most users conceive a pixel “unit” to be about 0.1 mm)

What should be displayed when the user’s system has no printer, for example, on mobile devices?  I contend that the displayed reference should be a rectangle related to the size of the display or windows.  As the user zooms in and out, the rectangle shrinks and grows.  Even without displaying the zoom level, the user knows that when the displayed rect just fits inside the physical display or  window, the zoom level is 100%.  The displayed rectangle for the size of the display or window references the drawing to the real world via the real world dimensions of the physical device the user is holding.

For windowed systems (where windows can be resized), should the displayed reference rectangle be:

1. the current window size?
2. or the maximum possible window size (the display size less certain menu bars and other widgets)?
3. the display size?
4. something else, for example a ruler?

(1) might be disconcerting to users: when they resize a window, the reference rect resizes.  A user might expect a reference to be constant except under zooming.  The reference rect is not very constant if it changes under both zooming and window resizing.  On the other hand, it is not such a difficult concept for the user to grasp.

(2) might be disconcerting to users: the reference rect refers to a size that is only knowable when the window is maximized.  The user must learn that said size might exclude the menu bar and other widgets.

(3) might be disconcerting to user: the reference rect at 100% zoom might not be fully visible, since the maximum window size might be smaller than the display size.  Since a user cannot see the entire reference rect at 100% zoom,  the reference rect would not be enough for the user to know when they were at 100% zoom.

Another design issue is, should the reference be a single rect or a grid?  If it is a single rect, the user may lose it by panning too far (but they can find it again by zooming out.)  If it is a grid, the user can’t lose it by panning, but the grid may be excessive noise.

Another design issue is, should the reference rect me hideable?  Does hiding the reference rect mean that the drawing is unreferenced to the real world (and for example, would only have pixel units if exported?)

This discussion is related to the SVG “viewport” and “viewBox” attributes or entities.  Using those, you may reference an SVG drawing to the real world, although it is not strictly required (since default units for SVG coordinates are pixels,  which again are not real world standard sized.)