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.