Friday, June 10, 2011

Process Control

Since my last post I've spent my time on the firmware working in "process control". This basically means dealing with things going wrong, or e-stop and limit switch operation. This work was not very glamorous, not like the VectorBuffer or LightManager that have well-defined and limited responsibilities. There was no obvious best solution and I didn't sit down to really concentrate on it. I just poked at it when I had time, so progress was slow and frustrating. Most the work was done in the Controller class but it was still a lot of wiring of software components and managing many state transitions. It's hard to debug this sort of thing given that it's running on the microcontroller and I don't have the benefit of stepping through code in a debugger. I can throw in print statements here and there but it's a tough code/deploy/test cycle.

There are some things unique to microcontroller development that would be difficult to analyze with print statements. Raw experience and a little intuition can help. When the E-stop button is engaged or the limit switch is open (both "stop" conditions) all the lights turn on. I noticed that when I hit E-stop, then opened the limit switch, the lights when from bright to less bright. There's no "dimmer" switch, or alternate electrical path through resistors or something. The only way the lights can go from bright to dim is by toggling them very rapidly. So I knew I would be looking for a spot in the code that would turn them all off then back on. I determined the state was switching back and forth from E-stop mode to limit switch stop mode. With each change in mode the LightManager resets the lights to off.

I decided to go with the polling approach for both E-stop and limit switches. There's no need at all for a hardware interrupt on the E-stop button since the other set of poles disconnects the power to the stepper driver control signal circuit. The limit switches probably could benefit from hardware interrupt. It appears there is about 60-70 milles of travel on the limit switch past the trigger point. That's like 600 steps on the motors. Polling might be fast enough to stop it before the motors crush the switch. I intend to test it well within the hard limits of the mill with stop blocks hot-glued to the machine so they should pop off if the machine overruns the limit switch before the firmware can stop things.

Anyway, it's in pretty good shape now. I've run it through its paces in manual mode and with a program run. There will certainly be tweaks, but it's clear the safety measures are in place and I can mount the motors.

No comments:

Post a Comment