Project Chronos

FEB 6 2012, uploaded updated Chronos Calibration instructions for the calibration routine. Note: this is not the same as the test and calibration tool which is used to determine button values and help debug problems on Chronos hardware. These are the updated instructions on how to calibrate your Chronos 2.0 controller to the motor and rail. JAN 22 2012, Uploaded new CHRONOS_2_0_JAN_23_2013.ino firmware This update increases Chronos 2.0's adaptability to other types of timelapse systems such as belt drives etc. There are now 3 motor speed selections in the Calibration routine. HSPD = The speed of the motor in POS mode. LSPD = The speed of the motor in MGO and SGO modes. SPD3 = The speed of the motor when microstepping. There is also now a new field in the Calibration "thr" This stands for threshold. This is the percentage of movement where microstepping begins. Select between 1-100, if chosing 30 then any routine that moves less than 30% of the total distance of the rail will enable microstepping. if using 100% then it will always microstep, use 1% and it will probably never microstep. The CONT mode has now changed, it still only moves the distance selected but now has 149 different speeds rather than 10, it no longer estimates the time required to move the distance. -------------------------------- Bug Fix, Dec 29 2012, 200 step option not showing up on hard counterclockwide on live ramp. File was too large for MAC. Eliminated HDR 5 mode to free up space. I dont think anybody will use HDR5 anyway. Tied motor movement to 1/2 of top speed selected. this should make it work easier with belt drives. ------------------------------- Chronos 2.0 The latest version of the code is the final version. There will be no new features added, only bug updates. I have removed the revision history. This version requires an Arduino R3. The Non-R3 arduios do not have enough space for this code because the bootloader is too fat. At this time of 25 Dec 2012 there is only one known bug which i have been trying to trace down. This bug ONLY happens when using SGO where the first step is about 2-3 times longer than it should be. I have found a couple situations where I can re-create this, and it requires a certain combination of "steps per cm" and distance moved. This only happens on the first movement sequence, all following movement seem to be perfect. So the worst case scenario if this happens is you might want to remove the first frame. If you are able to find this bug and repeat it please contact me and let me know so it can help me track it down and fix it. I have tested this code extensivly running hundreds of routines with various ramps, repeats, reversals, varying distances, drift modes, live ramping, etc. Everything works. When you first use this code you MUST run the calibration routine. Also remember each time you make a change in the calibration routine you must reset the arduino or it might not take effect.