The servo controller I've been building is meant to interface to a motion generation system. In the hobby CNC world, that's probably Mach3 or EMC2.

Mach3 uses the parallel port to generate signals that describe motion. It's often referred to as DIR+STEP signals. One line is the direction, the second is pulsed for each increment of movement. My servo controller was written to interpret these signals, but I didn't have a parallel port on my "legacy free" desktop to test this. A trip to the PC shop got a 2 Port PCI parallel port card (a Sunix 4018A Multi-I/O Adapter) for $35 (I could get one a few bucks cheaper, but the cheap shop had around 25 people queued at the counter!).

Unfortunately the Sunix card isn't just a "standard" parallel port. It doesn't appear at IO address 0x378 & 0x278 like a "standard" port (these are the addresses set by default in Mach3). Being a Plug & Play card, the IO addresses are assigned by the BIOS/OS. Windows XP's Device Manager shows the addresses the card had acquired.

I was hoping that the few ranges it had were still IO compatible with a standard parallel port. I entered 0xC000 as the port address into Mach3, attached the CRO to the port, and jogged the axis. Success!

A couple of wires were added from the parallel port break out board to my controller, and a test was in order.

The background is the standard Mach3 screen. Lower left is the motor. Lower right is the serial terminal output from my controller. The terminal output is: [0] positional error, desired position, output strength | temp diag numbers

The error sits at around 30 and peaks at 100. The motor is fitted with a 1200 pulse encoder (Mach3 configured for 0.25"/rev screw), meaning that's 9-30 degrees (0.16-0.55mm) out respectively. That's not bad for a system that's not been tuned properly (at all really - Kp=100, Ki=100, Kd=0).

I've added simple serial command processing to the controller, and you can adjust the PID parameters on the fly now. This will certainly help in getting the final tuning values.

More thorough testing is still needed. I need to push it until it breaks, and see what it can withstand. I also need to do some "quality" PID tuning. But for the moment... I'm a little pleased with myself.

Tuning the PID values for the servo controller is going to mean getting an easier method of communication with the device.

At the moment, to adjust anything, I change a variable in the source code, recompile, and reflash the controller chip. Not easy for quick testing of a minor change. Especially, since it means removing the chip from the prototyping breadboard, inserting it into the development board for programming, and moving it back again for testing. Argh!

I am going to need data coming out to judge the performance of the controller (measure errors, etc). I am also going to need data going in to quickly adjust parameters. I had added some simple serial output (for a quick debug), but this will need better management as the system is quite timing critical (the current serial output routine blocks signal processing while it waits to send the bytes out).

A few quick adjustments saw the outbound data buffered and dispatched only when the UART is ready to accept it. An inbound buffer was also created for inbound commands. A simple set of commands were implemented, and now pressing "A" & "S" in a terminal window rotates the motor forward or backward 1 revolution (1/6th revolution for lower case). "Z" will return the motor to its "zero" position.

The controller now regularly outputs the current position, desired position, and output value. Before launching into PID tuning, I might run a few tests to check that the encoder decoding routines function accurately, etc. I'd like to test the control decoding, but I've just realised... I don't have a system with a parallel port!

I already had my controller connected to the motor driver and to the motor. What was missing was the position feedback, and with my encoder fitted, the first test with feedback was ready.

I'd already written most of the controller code including the quadrature decoding necessary to understand the encoder's output. I patched in the encoder's lines to the controller, and set a low voltage for the motor driver. Setup done... I gingerly switched it on.

Nothing happened. So, I bumped the shaft and the motor took off. I had considered the possibility that I would get the encoder's output and the motor's input reversed. Knowing this, I reversed the motor leads.

Nothing happened. I bumped the shaft...nothing happened. I tried to turn the shaft... I couldn't. Success! I connected a shifter to the shaft and turned it. The motor pushed back. Considering the PID controller had no tuning, I was quite surprised by the initial response.

This static system was a little uninteresting, so I added a simple increment in to a timed routine to give it some movement. The results were very rewarding, and raised a couple of areas of concern.

Cogging. This demonstration makes the cogging extremely visible. The controller pushes through the natural attraction to one "cog" position, and once it reaches the influence of the next, it races toward it (and then the controller slowly recovers).

Large deviations from the desired position (like an idiot pushing a shifter on the shaft) recover very quickly, but the smaller ones are very slow at the moment. At this point, it's important to remember that the PID parameters have not been tuned at all. In fact, you can see the effect of the default (1) values in this situation:

Proportional - The further away from the desired position the more power applied - gets results quicker
Integral - The longer it's away from the desired position the more power applied - overcomes a constant opposing force (cogging torque, rubber band)
Derivative - The quicker it's approaching the desired position the more power removed - dampening to help stop overshoot

Tuning, tuning, tuning! The key to success here is tuning the unit. Just one problem, the tuning is specific to the circumstance of the unit. For example, in current no-load conditions the parameters would need to be set to respond quickly enough to over come the cogging jolts. But at its final destination, there will be pulleys, belts, shafts and screws attached. All of these components will add inertia and friction, greatly changing the characteristics of the system. The cogging torque may well be irrelevant when lifting a 100kg machining head with a badly lubricated screw. Irrespective of what is relevant where... I do need to devise and document a simple and repeatable tuning method for this controller.

I dream of a single button...

Having completed my machining exercise, I fitted the rotary encoder to the motor and had a play.

First thing was to check the encoder even produced any output (I could have broken it). I added 5V and plugged A & B into the CRO. Two lines at 0V... not good. I touched the shaft, and the lines wobbled. Yippee! So I powered the motor via an adjustable supply, to see what it looks like when running.

Things learned:
* My 36V motor will turn with just 0.5V applied (that's cool)
* At very slow speed with no load, the motor has some serious cogging

Next... plug it into my servo controller.

Spin motor left, spin motor right. Easy enough. The next step is to get positional feedback by mounting an encoder on the motor shaft. Sounds easy enough, doesn't it? But since my motors don't have a shaft on either end, I'll need to add an extension.

Luckily someone much better than me has already done this, and put nice instructions on the web. How hard could it be? It would also be my first real piece of work on the new mill.

It didn't go completely smoothly, but no fatal mistakes were made. A couple of cubic millimetres of material were removed that didn't need too... and a bit of extra glue.

At the end of the day... I'm fairly happy with the results.

In my effort to get BlogEngine.NET running under Linux I've been chasing a few issues...

I had Mono 1.2.5.
Had a problem with HTTP file uploads from Windows based browsers.

I upgrade to Mono 1.9.
Fixed the problem with HTTP file uploads from Windows based browsers.
Introduced a problem with URL rewriting.

I upgrade to Mono from SVN r101230.
Fixed the problem with URL rewriting.
Introduced a problem with master pages in a different path from the content page.

I hacked up System.Web.UI.TemplateParser.cs r101177 with an ugly work-around.
Fixed the problem with master pages in a different path from the content page.
Introduced... who knows what else.

I may have jumped in a little quickly in labeling the current BlogEngine.NET release a dud. A couple of the issues (not all) I've run into are... well, not really BlogEngine.NET's fault.

There was the case of me being stupid. During serving, BlogEngine.NET remaps URLs from a friendly "slug" format to a particular page and query string (GUID of post).
For example: /post/2008/04/Quick-to-judge2c-Quick-to-anger2c-Slow-to-understand.aspx maps to /post.aspx?id=bf673029-6f24-4e31-87fd-62c53abfb857
Unfortunately, this wasn't working. An request for "/post/2008/04/..." was turning into "/post.aspx.cs/2008/04/...." which threw a 404. Huh?

Oh, I ran around in circles for a while on this one. Mono was adding ".ASPX.CS" to directories as part of URLs. WTF? After plenty of scratching and confused looks, I traced it back to Apache. Apache has a feature, MultiViews, which was enabled on my site. What's it do? It messes with your mind.... "If the server receives a request for /some/dir/foo and /some/dir/foo does not exist, then the server reads the directory looking for all files named foo.*, and effectively fakes up a type map which names all those files, assigning them the same media types and content-encodings it would have if the client had asked for one of them by name. It then chooses the best match to the client's requirements, and returns that document." In my case, "some" did not exist, and it did a match on "some.*". Turning that option off fixed the problem (I had previously worked around this in code, but could now toss out the nasty hack).

An issue with BlogEngine.NET on Mono under Linux was with its file upload capability... it was bugging out. This was caused by a Windows browser providing Windows style paths "C:\Dir\File.Ext" during HTTP file uploads. The FileUpload control under Mono extracted the file name using Path.GetFileName... which uses directory separators relevant to the system it's running on. It's not expecting to try and process a Windows path on a Linux box. I logged a bug for this, but it was already fixed in the new Mono release. I don't think I should expect a product to work around bugs in Mono when a newer release is available that addresses such issues. I was using 1.2.5, and there was recently a 1.9 release. So I upgraded.....

1.9 appeared to introduce some new bugs. One breaks HttpContext.RewritePath... which is needed by the groovy post name remapping feature! Argh! This was fixed about 10 days ago, but I'll need a bleeding edge release to get that fix.

I've tried to swap in the updated System.Web.dll from a nightly build, but it appears to depend on other changed DLLs (sigh). So, please bear with me whilst I chew on this bit of gristle. I might have to recompile my runtime from SVN. Ho hum...

P.S. It's not all bad... I have noticed at least one other thing that since the Mono upgrade have just started working!

I've pointed out before that I'm going to take a crack at this blogengine.net thing. That all started in November. It's now March and I thought I'd update to the latest release. Just before Xmas, 1.3 was released, and included the tagline "Mono is now fully supported out of the box". Woohoo!

But, it's not quite right.

Four months after "Mono is now fully supported out of the box", I went and grabbed the latest released source and did an install. Disappointing. Many bugs and issues are still there. A number of pieces of functionality fail outright. The code is still littered with Windows reference paths and other assumptions. Bugs exists that only surface under a different implementation (like Mono on *nix).

I've started submitting to the Issue Tracker on CodePlex. I'm not hopeful as the issue tracker is full of n00bs screaming about how they couldn't get something to work. Let's see how it goes.

I've got my mill now, and I've had a little play with it.

One of the things I've noticed is the amount of play in the hand-wheels before they move the table. After turning in one direction, the hand-wheel will move back an indicated 0.2mm before they engage again. This means if you're using the markings on the wheels alone, you may wobble about by 0.2mm.

I took a quick measure of the change in distance between the bearing block and the wheel mount during a left to right transition: 0.1mm. The details of how the screw is mounted to the table is hidden a little, so I disassembled it to get a good look.

Screw (with pin), first thrust bearing, the bearing mount, second thrust bearing and hand-wheel mount

It's pretty easy to see where some slack in the system comes from... there is nothing holding this assembly together tightly. It relies on the placement of the pin and pin bores (it's important to keep in mind here that this is a economy Chinese machine, and not high precision equipment).

With the screw released from the table, I measured the movement of the screw against its "nut" on the saddle: 0.1mm.

0.1mm in the nut + 0.1mm in the bearing mount = 0.2mm total.

At the moment I'm not looking to eliminate this movement. I'm just looking to identify it... I just had a wild realization. In talking fractions of a millimeter (mm), it makes sense to use the next prefix - micrometer (µm). I've never dealt with such little units before. 0.2mm=200µm. Microns baby... microns. We're talking about two and a half times the width of an average human hair.

Maybe I'll just shim it with some average human hair...