Viewport and Parallax Propeller reduce development time of exotic measurement systems

Background:

MagnetDrives AG is a company based in Zug, Switzerland that specializes in developing electrical motors and sensors for applications ranging from 60 mNm to 100 kNm. Recently, the company was tasked to develop and produce a resolver system for an 8 Megawatt synchronous motor. Put simply, they were asked to build a device which could accurately measure the angle of the motor’s shaft. This measurement is important to control and optimize the motor’s performance.

Problem:

MagnetDrives was asked to build an exotic measurement system in only 8 weeks.

Solution:

MagnetDrives chose proven off-the-shelf software and hardware to reduce development time of the resolver and qualification system. Pickup coils mounted on the perimeter of the 60cm diameter resolver detect the mechanical angle of the motor’s shaft. Theses signals are fed to a custom PCB that features a Tamagawa chip whose output is read by a Parallax Propeller microcontroller. The Propeller runs code to process the resolver signal and also compares it with a reference Renishaw measurement system in order to qualify the resolver signals. ViewPort is used to display the microcontroller’s results in real time using a familiar Digital Oscilloscope interface. ViewPort was also used to adjust calibration parameters on the fly and to export data to Matlab and Excel for later analysis.

Chris’ CNC Controller

Having at first stumbled with debugging on the propeller, I read about ViewPort on the forums. It looked promising and the entry-level price couldn’t be beat so I purchased it. After using it for about 6 months now I can say without hesitation, I could not imagine programming without it! There are a couple of features that really make this an outstanding debugging tool for me.

First is the electrical interface, it allows you to communicate with the propeller using the same USB connection as the Spin Tool software uses for downloading program. No cable switching, no extra pins required.

Second is the oscilloscope display. Watching digital values (variable contents) works in most debugging sessions, however, being able to display those variables on the scope allows you to quickly see trends in the data that are hard to follow just watching numbers. This feature has proven to be paramount in helping to “see” what is going on inside the propeller while debugging the motion control software I write. For example, working with acceleration and deceleration, you need to be sure your ramps are smooth and consistent, Watching numbers change every millisecond is impossible! Watching the plotted line on the scope shows me the velocity changes and because the time base of the scope is adjustable, I can see a substantial amount of data all at once. Most importantly, even though I am analyzing a large amount of data, the plotted line makes interpretation of that data instantaneous!

Third is the Logic State Analyzer display. As with the scope display, it allows you to see visually a graphic representation of data that you can interpret much more easily than a series of numbers. I use this to monitor pin states (I/O), and see the relationship in the timing of those states that is very critical for motion control. I also use the LSA for watching Bits of variables. Being able to easily monitor bits within variables a programmer is more likely to utilize the bits instead of wasting a whole long or byte on a simple “ON – OFF” state.

Working with multiple cogs and shared core memory is a wonderful feature of the propeller, however, sometimes it can be terribly frustrating when a variable is changed and you don’t know when it happens or which cog caused it. I had a situation where one of the velocity parameters was changing. What I was able to observe with the machine is that I could run a CNC program, then when I tried to run the same program again, the velocity would be much higher for a few milliseconds then stabilize at the desired rate. Using ViewPort, I was able to quickly identify the duration of this event and more importantly when it occurred relative to other events. Knowing the relative time when it occurred I was able to determine the cause of the problem was due to program execution speed. A spin program executes much more slowly than a PASM program and as such, many steps of motion already happened before the spin routine could update the velocity.

Motion control for CNC applications is a bit different than general motion control. With CNC, every multi-axis motion MUST be synchronized to insure “perfect geometry”. Just watching a machine move can be very misleading as there were many instances where I thought the motion was “perfect”. This is again where ViewPort helps you to visual the data! Consider a motion along the X and Y axis where one axis moves a small distance relative to the other axis (resulting in a shallow angle). The axis that is moving the short distance must distribute its steps evenly throughout the duration of the motion to create that straight line at the desired angle. Using the scope function of ViewPort, I was able to watch the motion graphically on the plotted lines to monitor that motion. All too often what appeared to be a “perfect motion” was in fact flawed.

When developing the circular interpolation routine I noticed that the circle wasn’t exactly round, rather, it was like an egg tilted at an angle. This could be seen with a plotter pen installed in the machine as if it were a plotter. While being able to see the physical problem is good, seeing the cause wasn’t as easy. Using the ViewPort DSO, I could plot the positional data for the two axes and compare them side-by-side. This allowed me to see that both axes were executing the geometry correctly, just that they were out of synch with each other. Once the problem was understood, a solution could be made.

This screen shot shows the positional data during an X-Y circular motion. The problem I was having is a circle that was not round but could not determine why. You will notice on the Red plot, there is a linear section at the beginning. With that visually understood, I was able to back track through the code to determine that the previous linear motion was causing a start delay on that axis.

This screen shot shows the buffering of the CNC commands as they are fed into the Propeller chip. The particular importance here is to help determine the “wait” times for when a motion command is completed and when the command shifts from the buffer into the active data section. Monitoring this transition of data is critical to maintaining a continuos tool path without hesitations between moves. Furthermore, this plot also showed me when the command arrives into the Propeller and is placed in the buffer. Again, timing is critical to make sure the data stream keeps up with the motions.

Thanks Chris for the wonderful writeup and inspirational project.

Harley’s Z80

Background

The Zilog Z80 is an incredible microprocessor. It dominated desktop and embedded systems from its introduction in 1976 and was the first open-source microprocessor.

Harley, a retired electronics engineer from Oregon has been working with Tom to emulate the Z80 for quite some time. The first design- back in the late 80′s was implemented entirely in TTL. 3 separate boards were required to emulate the display/keypad, control logic, and pod logic. Slowly, the TTL logic has been replaced by hobby microprocessors. At first the 12 IC’s responsible for the display/keypad was replaced by a single PIC microcontroller. More recently, a pair of Parallax Propellers has replaced the 55 TTL components responsible for the control logic.

Obviously, emulating the control logic for the Z80 is challenging- numerous signals need to be routed and accurate timing is critical.

Problem

Before Viewport, Harley relied on a 5″ b/w monitor, an Oscilloscope and even a Logic State Analyzer to debug the software responsible for the control logic. He used the b/w monitor display status information from the emulated Z80. The Oscilloscope and LSA were used to analyze signals going to and from the Propellers.

This setup worked- but was not ideal. Changing the information shown on the monitor was very time consuming- and of course only the latest values were shown. Wiring up handfuls of LSA probes also wasn’t easy- or safe. Documenting measurements from traditional scopes and LSA’s is also not easy. Lastly- a tv monitor, an oscilloscope, and an LSA and their required equipment take up bench space, consume energy, and are expensive.

Solution

Harley has now integrated Viewport and the 20 Mhz option of the QuickSample plugin into the programs running on both Propellers to replace the monitor, the oscilloscope, and the logic state analyzer.

Viewport’s QuickSample technology allows Harley to view all 32 bits of the Propeller’s IO port at any timescale he needs- up to 20Mhz, giving a top resolution of 50ns. These measurements are taken in a separate cog on the Propeller- while the Propeller is executing the Control Logic program. From within Viewport, Harley is able to trigger on different bits, change the timescale, and share his measurements by simply copying and pasting his result into emails or Word documents.

Viewport’s interface lets Harley see the LSA bit traces and the value of several variables from the program. When Harley wants to view information from other variables they’re just a click away. The status variables can also be graphed over time to show how variables change as an emulated program executes.

Harley has also taken advantage of Viewport’s ability to edit variables- while the program is running. This lets him change the control logic’s configuration on the fly.

Harley’s Viewport-enhanced setup is now much leaner and allows him to debug his Control Logic more efficiently

 

“Before Viewport, I had trouble programming and debugging the Propellers for a Z80 emulator design- it was difficult for me to see what was happening inside- there is only so much a blinking LED can tell you. Now, I can see AND edit variables in my program and also watch what’s happening on the 32 IO lines at high speed with NO wires!”

Harley

Ingolf’s Messmoebel (Measuring Furniture)

Background

Electronics can be a lot of fun- when you’ve got the right equipment. Today, most serious hobbyists own a power supply, a multimeter, a frequency generator and an oscilloscope. This setup allows them to quickly and easily carry out experiments and build interesting projects.

Ingolf, a physicist, likes to understand things- his motto is “to measure is to know”. Thirty years ago, he built his first Messmoebel from scratch. His Messmoebel (german for “a piece of furniture which measures”) combines everything he typically needs in a nice wooden cabinet. It contains an audio amplifier, a two channel, 10 MHz oscilloscope with input preamplifiers and time base, function generators (Wien Bridge and voltage controlled oscillator), and a multimeter. The power supplies provides variable voltage and current between -12 and 12 volts.

Problem

Ingolf’s Messmoebel still sits proudly in his lab, but more and more of Ingolf’s project rely on computer control. Now, the ideal device would be connected to a computer- giving him more flexibility with his experiments while still being easy to use. His requirements were simple: improved functionality, integration with his computer, and of course be enclosed in a wooden cabinet. And it had to be built in an afternoon.

Solution

The Parallax Protoboard is the heart of the new Messmoebel. It’s an affordable way to connect 32 IO lines to a PC while also providing a high performance Propeller chip.

Viewport- the brains, runs on the PC and the Propeller to provide these features:

  • Pulse Generator: 1hz-128Mhz
  • Configurable output patterns ranging from accurate dc voltages to sine waves, to TV pictures
  • 80Mhz Logic State Analyzer (under development)
  • 40Mhz High Speed Oscilloscope with 8 bit resolution on two channels
  • 8 Channel Oscilloscope with up to 12 bit resolution and 100Ksamples/second
  • 8 Digital IO lines- these can be used to drive servos, lights, or used to sense switches, etc.
  • Power supply for 3.3, 5, and variable 0..9V

A breadboard area lets Ingolf prototype simple circuits while the front panel allows connectivity to other devices. The Viewport Dreamkit software runs on seven of the Propeller’s eight cogs:

  • The Dreamkit Application runs spin code on 2 cogs to generate pulses, drive the front-panel interface, and control the variable power supply.
  • The Viewport Quicksample plugin runs interleaved assembly code on 4 cogs to provide up to 80Mhz of digital, or 40Mhz of analog sampling.
  • The Viewport Conduit runs assembly code on 1 cog to transfer data at 2 Megabaud over the USB cable.

This leaves Ingolf with 1 cog for his experiments. In his first experiment with the new Messmoebel Ingolf analyzed the SPI communication between the Propeller and an ADC chip. With Viewport, he triggered on the chip enable signal, took measurements of all IO activity, and then pasted his result into a Word document. With his old Messmoebel this same experiment took much more work: connect wires to the right pins, take each measurement separately, take photos using a camera, and then Paintshop the traces into one picture.

Kyle’s Motor Controller

Background

There are many ways to control a motor’s speed. For some applications it’s sufficient to turn the motor on or off via a switch or transistor. For more critical applications, the motors speed and direction should stay close to the target values- even when load is applied.

Kyle, a budding robot enthusiast (he’s 11 years old), is currently investigating different methods of locomotion. For his robot projects, he and his dad have used continuous rotation servos, as well as car motors driven by speed controllers. For his latest project, he chose to measure the motors speed using a quadrature encoder and to drive the motor via an H-bridge. A quadrature encoder outputs 2 signals whose frequency and phase correspond to the motor’s speed and direction- this technology is used in most non-optical mice. An H-bridge drives a motor at any speed and direction by varying the length and polarity of the power supplied to the motor. Driving an H-bridge requires at least 3 pins- forward, backward, and enable. Since all of these signals are time critical, and the control logic difficult to calculate empirically, Kyle faced quite a challenge.

Problem

To measure the motor’s speed and adjust it’s power, 2 inputs and 3 outputs needed to be monitored. Furthermore, the feedback loop for the controller- in this case a full PID controller, required debugging and tuning. Without the ability to see the IO signals or adjust the PID’s parameters, this project would have taken much more time than it did.

Solution

Once the hardware was ready, Kyle was ready to tune and debug the controller. At first, he used Viewport to inspect the Quadrature Encoder signals. Once he understood how the phase determined the motor’s direction, he came up with an Assembly program to measure rpm on multiple motors and to drive the H-bridge for a given value. What was left was tuning the PID loop. A PID loop takes 3 parameters- the gain multipliers for the Proportional error, the Differential error, and the Integral error. Kyle used Viewport’s scrollbar to manipulate these parameters while monitoring the motor’s performance. He started by increasing the P constant, then adding I and D to yield a controller which accurately and quickly kept the motor at the desired speed.