Over the last months I’ve made a lot of changes to my motion control system. Almost all mechanical components have been replaced and its capabilities have been vastly extended,  including the ability to continuously rotate and home it for repeatability. 



To implement the new features I had to remodel and reprint all 3d printed parts. To minimize the printing times I implemented all changes manually first.  After drilling, sanding and glueing my modifications into the current model I was ready to model the new hardware. An overall goal here was to make components which might get replaced in the future modular.

I equipped the base with a cable channel to route the cables from the cable chain into the base where they are plugged into an adapter PCB. I also attached an optical endstop to the base to enable homing for this axis while keeping the possibility to continuously rotate.

The pan head has been modified the most. I added a mount for the rotary connector, which is a 12 channel slip ring connector from Senring, and a pin to engage with the endstop in the base. The back has been completely removed to make the gimbal slimmer and save material and printing time. To retain stability I added ribs on the back and Metal brackets on both sides. The top of the pan head has the same optical endstop as the base attached to it, to zero in the tilt motion.

The camera mount now has a cutout which holds the macro rail to prevent it from rotating and also a pin to engage the endstop on the pan head. The macro rail has been replaced with one that doesn’t suck and allows for easier mounting of the camera because the base plate can be removed. It also features a longer knob to tighten the plate which is easier to access while the camera is attached to it.

The rotary connector in the pan axis allows me to continuously rotate the rig without twisting the cables. The connection is stable enough to feed the motor connections of the steppers, as well as the endstop signals and supplies through it. The tilt axis will get such a connector in the future to allow for connections to the camera, from where I can supply it with power and trigger the recording.


The Electronics also underwent some changes. The Ghetto-style Tupperware container is gutted and gone. Everything is now on one stack on the Raspberry PI and mounted to a new end piece of the slider. The Arduino Mega has been replaced with an Arduino Uno as this version of my motion control rig will not utilize more than 3 axes onboard. A power converter also fits onboard which powers the Arduino as well as the Raspberry Pi.  This makes the only external component the 12V power brick. 

The endstops were straightforward to implement. For the mechanical Endstops I just had to connect the “normally  closed” and the “common” pin to the endstop header of the arduino. In the grbl settings I configured the axis accordingly and was done. The optical endstops were just as simple, except they also needed a supply voltage. 

To make the gimbal detachable from the slider base I added an adapter PCB inside the base. The cables from the cable chain and from the gimbal are plugged into the PCB as well as the endstop cables of the pan axis.

When I connected the steppers to the rotary connector I ran into a problem. The motors only stuttered when I tried to move them. I measured the resistance of the connector as 3 Ohms. The stepper measured at about 5 Ohms. I figured most of the Voltage was lost in the connector and I had to do something.

Well, what I definitely did not do was:

Good thing that didn’t happen.


To enable homing in the grbl software you just have to write the value 1 to setting 22 and the fun begins. With the settings 23 to 27 you can configure various things regarding homing speed and direction. If you are using normally closed limit switches like I do you have to invert the limit pins by writing a 1 to setting 5.  In the config.h file of grbl you can set up how many and in which order the axis will be homed. I’ve set it up to home the slider axis first and then the two rotary axes. After that you just have to send the homing command to the controller and grbl does its thing. For that purpose I’ve used the button on my remote which already was labeled “Home”

While I was at it I rewrote the complete architecture of the control software. In the original design the gcode sender for the grbl controller was tightly implemented in the keyframe editor. This rigid implementation made adding axes a pain in the ass and difficult to maintain in the long run. Now, everything connected to the slider will be handled as a generic interface and will automatically be included in keyframes and jog moves, no matter if the interface represents a full motion control rig or a simple lamp. Everything can be keyframed now. 

I did this to include the new rotary platform I’ve built. To my surprise this works really well. Both grbl interfaces, via serial and telnet, move simultaneously despite only one interface getting a gcode command at a time. There is no synchronization necessary other than sending gcode rapidly and keeping the buffers filled. Nice.

An earlier project of mine was a gui for a 4 by 20 character LCD. It features hierarchical tree navigation, editing of numerical entries, triggering of functions, user defined full screen pages and switching between multiple pages. I decided to use it to adjust jog speed and clear alarms for both grbl interfaces as well as a fullscreen hud which displays the state of all connected components.  The gui is controlled with 6 buttons: up, down, enter, escape, next page and previous page.The drawbuffer of the gui is created locally and then sent to the remote control via mqtt. That way I don’t have to change the remote control software when the gui changes.