-
10-23-2022 - Clock homing
10/23/2022 at 02:03 • 0 commentsThis log covers a software test, about homing the minute and hour pointers to accurate time.
The test includes:
- Connecting to the internet (Earlier test)
- Setting the RTC time (Earlier test)
- Convert time into 12 hour format, then into 360 degrees formatThis was pretty easy, by subtracting 12 hours we can get it in 12 hour format, and then by multiplying hours with 30 and minutes with 6 we get it in the "unit circle" format of degrees. With other words, represented as a circle...
- Run motors until destination is reached
Basically a function that gets the hours and minutes in degrees, then sets the motor "wanted" position. Starts while loop, that runs motors and breaks when BOTH motors has reached its destination. It sounds so easy when written. Also we remember that we cant just set the hour pointer at 02 O'clock, when the minute pointer is at 55 minutes. The hour pointer is also dependent on the minutes.
The result:
Console output:
Next I would like it to be a little more smooth and accurate, it seems a little off somehow with the minutes.
Also next is the last important step, making the pointers go around ... smooooothly.
-
10-04-2022 Testing the accelstepper library further
10/04/2022 at 21:59 • 0 commentsShort video of testing the accelstepper library with some more precise and smooth movement.
I am thinking about homing the stepper motors in reference to the minutes and hours.
Next I would like to step on the interrup of the RTC, so that the stepper motors Is moving according to the real time.
-
09-22-2022 Testing the RTC time accuracy
09/22/2022 at 21:54 • 2 commentsBasically I tested and followed the tutorial from workshop. However the accuracy of my RTC was at best 30 sec off.
Instead I made a test where I connect to an NTP server, retrieve the time and set the time in the RTC module accurately. This conveniently also fixes the RTC modules inaccuracy over active time, which I've read could be anything from seconds or minutes a day, depending on the module.
Picture below is the accuracy of the NTP server, which is basically one to one.
The picture below is the RTC time which has been set with the data from the NTP server and very accurate. Will check how much it differs from the real clock over time. But should be no problem because now we can connect to the internet and update it.
You might be wondering why not just throw the RTC in the thrash where it belongs? We might not always have a secure connection. This is why as soon as we have an connection we just update the RTC. Will this kill the battery? Most certainly it will, but that is tomorrows problems.
I will push all the test software up on my github when I the project is finished.
The next I will look at is making an interrupt on the squarewave from the RTC and make the motor move according to the time! :)
-
testing the motor and driver 09/19/2022
09/19/2022 at 12:40 • 0 commentsFirst I made some test PCB's for the x12.17 driver. I used 28 SOIC boards and soldered away, and burned my nose, don't ask how! I wired everything up, credit to this guy : https://guy.carpenter.id.au/gaugette/2017/04/29/switecx25-quad-driver-tests/. check out his other stuff, like how to remove end stops from the motors if you happened to buy them with end stops as I did. https://guy.carpenter.id.au/gaugette/2012/04/04/pulling-out-the-stops/
I tried 2 different libraries to control the stepper motor and manually.
SwitecX25 / SwitecX12 library
Guy.carpenter added an extension to the SwitecX25 library to use with motor driver called, its called SwitecX12.
Conclusion: Couldn't make it work, and I have no idea how.
Manually
I manually pulled step pin LOW and HIGH with correct delays and such according to the datasheet of the motor driver.This was actually working, it was smooth and controllable and also microstepping. For a single motor this could suffice.
Conclusion: Great but probably not ideal for more than one or a couple steppers, they would not be synchronized, as we are calling blocking functions. This would ultimately (probably) screw up the timing and steps in the long run. I could make my own stepper library, calling timers, flags, triggers and what not. But I'm too lazy and I hate low level.
Video of manual stepping:
Accelstepper / continuousStepper library
I used the Accelstepper library to run a simple test on both motor pointers. Where I use the AccelStepper::DRIVER setup. This seems to work alright, I will try to look more into this library as I believe this is the way to go. This library supports drivers, uses non blocking code, so multiple steppers could be used, and it is quite popular.
See AccelStepper documentation here:
https://www.airspayce.com/mikem/arduino/AccelStepper
https://hackaday.io/project/183713-using-the-arduino-accelstepper-library