The effective length of the pendulum is what determines how fast it will swing. The bob is the heaviest component, but all parts of the pendulum help determine the center of mass used to set the effective length. The long lightweight tip determines the overall length but barely changes the effective length. It's great to see the stronger magnets making the clock run better. It must be with the newer electronics. The old electronics uses two side by side magnets. I never measured them to see if they are the same polarity or opposite on each end.

I don't mind testing the board for scientific purposes. I am also at a loss about what is happening. Before sending it, here would be my test plan to reduce everything to the bare minimum and add components back one by one to find out what is loading down the 5V supply. 1) Remove all components from the CNC Shield V4 board. Plug the USB cable into the standalone Arduino Nano and measure the voltage between the 5V pin and GND. 2) Plug the Arduino Nano into the CNC Shield V4 and measure the voltage again. 3) Plug the RTC in and measure the voltage. 4) Plug the TMC2208 in and measure the voltage. 5) Plug the stepper motor and cable in and measure the voltage. The first step that measures a voltage drop should help identify the culprit.

That sounds like it could be the problem. Could it be the USB cable? It seems like you have ruled out almost everything else.

Stepper motors operate on current. Any voltage high enough to send the desired current is sufficient. A 3 ohm motor could theoretically run on 3V with 1A passing through the windings. The clocks only need a few mA to rotate the gears. The stepper motor driver (TMC2208) has a minimum Vmot of 5V and we take advantage of this by shorting the 5V USB power to Vmot. This is done with the diagonal jumper wire in the lower left corner of the CNC Shield V4. Many other stepper motor driver chips require 7-8V or more for the motor power supply. The TMC2208 was specifically chosen because of the 5V operation. Connecting a 12V power supply to the barrel jack would possibly damage all of the chips. It seems like everything should be working. The Arduino Nano and RTC are functioning properly. The motor and cables are tested with the proper connections. You have swapped out the TMC2208, so that should be good, but not 100% guaranteed. Maybe the board wiring on the CNC Shield V4 should be checked. Double check edits #1 and #2 to make sure they make proper connections. This is the edit that connects 5V Vcc to Vmot so the motor driver runs on 5V. You could check with an ohmmeter, or measure that the TMC2208 pin labeled Vm has 5V when the board is connected to USB. Also, try a different USB power adapter. I have seen one that was so weak that it made the clock unstable.

The Arduino Nano and RTC are working properly. The only things left are the TMC2208, stepper motor, and cable. You have swapped out the TMC2208, so I suspect the motor or cable. Have you measured the motor resistance at the end of the cable? Pins 1 and 2 should be connected. Also pins 3 and 4 should be connected. Leave the current adjust potentiometer near the center of the adjustment range.

The wiring looks good. My last comment seems to be lost. Typing it again. The motor is a good brand. I have the same brand P/N 17ME15-1504S motor and it needs a crossover cable with the two center wires swapped. An ohmmeter measures 3 ohms between pins 1 and 2 after testing it in a clock. Pins 3 and 4 are also 3 ohms. There was a misread on the jumper settings earlier. SP6 should use jumper positions 0011 instead of 0110. It doesn't change the debug, only the motor speed.

Correct, no jumpers because that would short Vcc and Gnd with the backside wiring edits.

I am not sure why the motor is still jittery after swapping the middle two wires, unless you still have the first swap of wires 3 and 4 in place. It may be best to test with the current adjust potentiometer set near the center of the range. It can be reduced to a lower setting after you get it working. The clock needs very little current and there is no need to overheat the motor or stepper driver with extra power. The jumper positions are documented in the sketch and should also show up in the serial debug monitor. Here is the code. The 4x2 header block defines the modes. Your photo shows 1110 which is a debug mode to rotate the motor, but not at the proper speed for SP6, which should use 0110. Jumpers in the 8 pin header set speed or set up debug modes CoolEN selects debug mode if inserted Resume, Hold, and Abort set speed to one of 8 speeds Parameters calculated any time jumpers are changed Motor speed settings (subject to change) 0: 0000 1.000 RPM reserved 1: 0001 4.630 RPM SP10 with 200 step motors 2: 0010 4.630 RPM SP10 with 400 step motors 3: 0011 3.600 RPM SP6 with 200 step motors 4: 0100 4.667 RPM SP9 with 200 step motors 5: 0101 6.944 RPM SP11 with 200 step motors 6: 0110 6.944 RPM SP11 with 400 step motors 7: 0111 20.00 RPM fast debug mode Debug routines 8: 1000 LED off no test running 9: 1001 LED on simple hardware test 10: 1010 LED on simple hardware test 11: 1011 Delay test LED will blink at 1Hz (0.5s on, 0.5s off) 12: 1100 LED on simple hardware test 13: 1101 RTC test LED should blink at 0.5Hz if RTC is working 14: 1110 Rotate CW Rotate motor one direction at medium speed 15: 1111 Rotate CCW Rotate motor in opposite direction at high speed

The motor cable colors are almost completely random between manufacturers. As far as I can tell, there are only two different wiring orientations. The wires can either be aAbB or abBA, where a and A connect to one motor coil, b and B connect to the other motor coil. I don't believe there are any motors with abAB. The TMC2208 board is wired to support motors and cables with the abBA configuration. If your board/cable has the aAbB configuration, then swapping the red/blue wires would reverse the motor direction but would not change the wiring orientation. Can you try swapping the middle two wires? The symptoms of the middle wires being backwards are that the motor jitters back and forth without rotating. It is most noticeable if you add the pinion or a piece of tape on the motor shaft. It might also hum. I hope this makes sense. If you have the IDE open while programming the Arduino Nano, click the magnifying glass icon to open up the serial debug monitor. It should report what jumper setting is recognized. Some of the modes are debug modes to test individual components like the LEDs or RTC. btw: this topic has come up a few times recently. I will start planning a video describing these symptoms and fixes. Also btw: thanks for the picture and description of the motor symptoms instead of just saying "it isn't working, what should I do?". Steve

Great looking clock. I really like the colors. 300g in the 8 day mode without a pulley makes the clock effectively a 4 day clock. The pendulum amplitude is probably just barely enough to keep the clock running. It wouldn't hurt to increase the weight slightly instead of trying to reduce it. My SP5B clock has been running a long term test since it was designed around January of this year. It has the 20 day gear set using a 6.5 pound (2.95kg) weight. The bearings needed to be cleaned after 6 months. Possibly, there was some residual grease leftover. Also, I had one stoppage where either gear 3 or the collar slipped and pushed against the escapement. The escapement is so lightly loaded that very little friction can make the clock stop. I adjusted it and it is running great again, although possibly not as strong as when it was first built. I wonder if silk PLA changes over time. My longest running clock used an antique brass filament that seems to have a harder surface than silk PLA.

Clocks have one of the most challenging gearing applications. The start/stop action means that the gears have no momentum to push through a high friction position. The drive weight needs to be large enough to start up again when the gears line up in the worst possible orientation. Gears cycle through three distinct phases as they rotate. The initial tooth contact has engaging friction with some sliding. A rolling action occurs during the sweet spot. Finally, there more sliding friction when the tooth disengages. Engaging friction is the highest of the three modes and the most troublesome for clocks. Cycloidal gears have less engaging friction compared to involute gears. Switching this clock to cycloidal gears allowed a reduction in drive weight by reducing the engaging friction positions where the tick is the weakest. Cycloidal gears might be more sensitive to misalignment errors in the center position. The set screw tilting the gear or bending the arbor could be an issue. The screw only needs to touch the arbor. There is very little sideways force, unlike the friction clutch screws that need to hold back the spring pressure. The gear 3 center hole stays tight inside the arbor up to the top of the screw. Maybe the narrow portion could be extended further upwards to help prevent the screw from tilting the gear on the arbor. Thanks for the heads up about the groups. Wix is forcing the change by closing down the forum feature. I may have to look into external forum software.

Sure, you can do your own conversion to wood.

Right now, all of my designs are completely optimized for 3D printing. The gears have just enough strength for printing. The gears, pinions, and shaft are integrated into single components. The front frame, back frame and base are also optimized to take advantage of 3D printing features. Different optimizations should be made for wood. I have plans to start converting some of the designs, but it is a long term project.

Great advice Frank. I was just about to suggest the same thing. These clocks have a second hand so it is really easy to test if the pendulum is running 5% slow. The friction clutch needs to have enough pressure against the gears to overcome the hour hand gear train friction. Two possible friction sources would be the hour hand not rotating easily where it passes through the frame, or the hour hand being pressed against the front frame because there is not enough end shake.

That is too astronomically rare to be a coincidence. Maybe you do have ghosts.

Yes, you must have ghosts that don't like the ticking sound. It is too much of a coincidence for several clocks to all stop at the same time. You would think nothing of it if one clock stopped last week and another stopped today. But if both randomly stopped on the same day, you would think there were ghosts or some other unexplained reason. Could it be a simple coincidence? How many clocks are you talking about?

There are a few possible reasons why the motors are spinning at half speed. The motors you ordered appear to be 200 step motors. The TMC2208 is supposed to be configured in 16X microstepping mode. Maybe it is somehow configured as 32X microstepping mode. If so, this is the first report of this happening. The jumper speed settings are properly recognized and configured as SP6. Swapping out the motor did not solve the problem. My suggestion is to use the delay settings listed above to double the number of steps given to the motor controller. It doesn't explain why, but it should give you a working clock.

Looks great. The gears really pop.

You are getting closer. The RTC tracking is a good sign. The board is configured for 16X microstepping, so a 200 step motor needs 16 * 200 = 3200 steps per revolution. The SP6 clock has a 15 tooth pinion driving a 54 tooth gear_2 for a ratio of 3.6:1, so the controller needs to receive 3200 * 3.6 = 11520 steps per minute, or 192 steps per second. The stepper driver should receive pulses with a high time of 2604uS and a low time of 2604uS to equal 192 full steps per second. Your clock should be running properly with 200 step per revolution motors. I am fairly certain that you have 400 step motors. One quick fix is to change the algorithm to produce twice as many pulses per second, each with half the duration. Open the sketch in the IDE and scroll down to around line 340 and change one of the cases. I recommend changing case 0 so case 3 is left untouched. Here is the code to replace the original case 0 section: case 0: // 3.6 RPM for SP6 with 400 step motors motor_steps = 384; // 3200 * 2 / 60 * 54 / 15 = 384 extra_steps = 0; // no extra steps needed min_motor_delay = 1245; max_motor_delay = 1312; break; Hope this makes sense

Did you do the edit to short the two pins on the RTC? That edit is needed to allow the 5 pin RTC to plug into a 4 pin header on the CNC Shield V4 board.