Universal axis controller

Along the lines of a universal power unit like the power cube it makes sense to create a universal controller that can be "plugged in" to whatever actuator system you need to control. Why let the control electronics/software for a system sit idle? Take the controller with you and use it in the machine you happen to be operating at the moment.

I assume this would be a distinct system in that it wouldn't be automated. So, automation systems could utilize the universal axis controller, but it would primarily be used by people as they move between different machines.

Characterizing an arbitrary arrangement of actuators isn't really straight-forward, but it will probably yield to some kind of nomenclature. Some sort of hardware description language is in order.

For example, an electric drill would have only one axis (or degree of freedom) which can be moved positively or negatively at different velocities. Drill

• Single axis
• Rotation
• positive/negative
• (angular) velocity

Or, arguably, the drill doesn't know or care that something is spinning, let alone how fast it's spinning. More accurately its "axis" is the variable-resistance switch that sends electricity to the motor. The state of the switch is what's important; the motor's actions are just a dependent variable.

That implies a high-level characteristic should be whether or not the axis control is closed-loop. If it is, then the feature being measured is important. If it isn't, then nothing at all is being measured, so things are much simpler. Okay, so the universal axis controller (UAC) should be an interface between an operator (human or automated) and the system with the axes. It should interface with and understand the signals of any sensors, translate those signals into whatever the operator needs to know, then translate control signals into whatever the axes need to move correctly. That's beginning to sound like a robot control system. Something like this Basic Input Output Elements thing.

If the point of it is to be easy to unplug from the machine and walk away with, then it would need to be a single unit. Just a box you can unclip or something. That means there will probably have to be some sort of associated family of sensor/actuator interfaces that are physically distributed throughout the machine. For example, maybe stepper motors would have their step control boards right next to them and the UAC would just send step signals to wherever the steppers physically are. In the same way, end-stop sensors would have their circuitry right there at the place where the sensing is happening and would just return ON or OFF signals to the UAC. That's how open source 3D printers are built, except that the stepper drivers are usually mounted on the central controller itself instead of next to the motor. It wouldn't make sense to clutter up the UAC with a dozen stepper drivers just in case that many were necessary for one machine.

Perhaps the UAC could be implemented in a FPGA. Or, rather, in an FPGA slaved to a computer. The computer would be the primary interface with the operator. The FPGA would be "programmed" with the correct "image" for whatever machine needed to be controlled. That would supply precisely timed signals to the hardware (operating systems don't work in real time). It would also mean the control systems could be simulated as they were needed, rather than having to be all sitting next to each other "just in case." An FPGA could simulate a few stepper drivers and end-stops and thermistors and whatnot for a 3D printer, or it could simulate a dozen stepper drivers for an industrial robot, or it could simulate a machine vision system for an automated crane...or whatever. If each control module is programmed the FPGA can just be loaded with a custom control image for each application.