February 28, 2010 by cronix
Posted in
I spent quite some time on the motors today. I wanted to see how things work and how the Slim application can be used to drive the motors. I am into computers a lot and I can comprehend the electronics of OpenMoco and de Arduino board.
Stepper motors are new to me. I have spent some evenings last week in order to read as much about them as possible, but I am still learning about stepper motors.
I bought some inexpensive motors from SparkFun to experiment with. I don't think these motors will be in my final version. The motor I am mentioning can be found here.
The stepper motor is connected to an EasyDriver board (version 4.2). I could not really find how the colored wires for the motor should be soldered to the EasyDriver board (besides some information about the motor itself). I soldered the motor wires as follows from A-B: Red, Green, Yellow and Blue.
I can control the motor by using the set_motor command in Slim. The move command is also working. I still have some difficulties understanding the steps and ramp settings. The combination with keyframs is also still not under control. Can I find any good information about this somewhere?
But now for the real question. The home command is not working. The motor is continuously going to another position when I use the home command. I set the value by entering:
motor 0 home 0. The last 0 is not in the help, but Slim does not accept this command without this value (as with motor 0 enable that also requires a value that is not in the help yet).
Why is my motor not returning to the correct home setting?
-
Did I connect my motor the wrong way?
Is this a flaw in the 0.82 software?
Am I using Slim not correctly?
I hope to clear this out because this is the last part of my test setup that I don't understand.
Cronix, There's an open bug
Cronix,
There's an open bug on this right now. (Matt had mentioned this in one of the forum posts.)
It will go home, if you move in the other direction - I expect to try and resolve this soon. (Everything 'looks' right, so I need to get down and build a debug version.)
If your motor is moving, you've set it up correctly =)
The extra arguments to home, enable, and disable are unfortunately due the generic command processing in slim, and a little thing that slipped past me when I released it.
For future reference, check out the data sheet on that motor: SM-42BYG011-25.pdf. Notice on the top right of the first page, there's a drawing labeled 'wiring diagram'. What it's showing are two coils, where red and green are one coil, and yellow and blue are another coil. The 'A' and 'B' on the easy driver reference a coil (two wires for one coil under 'A', and two wires for one cil under 'B') - you can hook them up in any order, as long as both wires for an individual coil are on A or B.
The steps setting is how many steps to take between each shot - if you know your gear ratio, etc. you can calculate how far is moved w/ each step. The ramp setting is saying how many shots to take to get up to full speed (causes a linear velocity ramp in the movement seen in the output video). So, if you said move 5 steps between shots, with a ramp of 5 shots, your pattern would look like:
move 1 steps
exposure 2
move 2 steps
exposure 3
move 3 steps
exposure 4
move 4 steps
exposure 5
move 5 steps
exposure 6
move 5 steps
...
!c
The homing bug was fixed in
The homing bug was fixed in last night's check-in to subversion. Along with the focus tap issue. I have not added selectable tap yet, but the fix for homing was one line, if you wish to add it manually, in the motor control pde:
becomes
Yay for silly mistakes. =)
!c
Microstepping possible? would
Microstepping possible?
would like to use microstepping drives with gearing, so I need a lot of steps output... (-;
is there a chance to optimize ramping for huge step - output??
up to now I can work with smooth, great moves up to 65000 steps which I can output with correct ramping - great work, thank you very much!!
but I would like to do up to 250 000 steps within one move.... (-; which factors could be filled in the
formula...? steps / ???;
shelfl_lo * ?;
Thank you very much!!
tim
// shelf where motor1 speed ramp starts and stops
unsigned int shelf1_lo = steps / 3;
unsigned int shelf1_hi = shelf1_lo * 2;
// we can't have our ramp rate be zero, which it would be
// if shelf_lo were >= the difference between min and max
// ramp rate. This happens when large moves (thousand+ steps)
Microstepping is a function
Microstepping is a function of the stepper driver, and not the engine - so it's supported. In fact, in my pan and tilt system, I use 8x microstepping and 120:1 gearing.
To allow greater than 65,536 steps would require a change to the underlying code, not in any algorithm, but in the data types used to store and manage the needed data.
You would need to change the data type used (currently unsigned int) for the motor steps setting to something like unsigned long. Then, you would have to modify the serial protocol such that it would accept a long, instead of an int, and then modify any calling code to send the proper data.
I have to ask though, why such long moves? I can't think of anything in the timelapse realm that would call for such long moves? On my pan and tilt, I'm microstepping 8x, and have 120:1 gearing -- meaning 192,000 steps per 360' revolution of either pan or tilt. This works out to about 123' movement at 65,536 steps. This would not work for timelapse at all, unless one had, say, a medium format sensor and a 300' FOV lens =)
Another side-effect of this is that you may quickly run out of data to store distance from home and steps moved with such giant moves. The largest integer size in the arduino is an unsigned long - 32 bits. Home distance has to be signed, greatly reducing the integer capacity. If one wants to retain home and steps moved settings, you would have to do a little hackery to emulate 64-bit integers using two 32-bit values.
!c
Cool engine - best of world
Cool engine - best of world support (-:
hey, it´s great - You´re right!! I did use an old surplus gearing... ok... more than 500:1 (it runs really slow ((-; and tried to combine it with 16x microstepping.... it was a little too much gearing.....
I should look for an normal gear and going down with microstepping... now
everything moves very smooth - thank you!!!
now i´m looking for an easy 4 or 6 button lcd interface (2rows) ... to select and fill in the variables directly to the engine (-; I found some pictures in the forum.... but are there some code snippets .pde for a lcd & button interface for arduino to select and change (up/down) values...is something like that integrated in the downloads ?
is there any hint how to find some code for such an button interface (need a cheaper solution than multi-touch or pda for testing:)
would be glad to find some of these arduino sketches - if only for testing motors and performing some "change variable for x steps" take up/down buttons "number of steps up /down" "save number of... steps" and "go" moves without uploading a new pde every testing-time ?
thanks
tim
Tim, Thanks for the great
Tim,
Thanks for the great feedback!
You're reading our minds =)
I plan to have 0.82 version of the engine ready to go production next week (working on documentation right now, tweaking serial commands, and finishing up testing).
Next week, I'm going to start on a control box using these:
Mini buttons pad set: http://www.sparkfun.com/commerce/product_info.php?products_id=8996
Serial LCD: http://www.sparkfun.com/commerce/product_info.php?products_id=9395
It will be a fork of the main engine, 'cos I'll also be adding DC (PWM) motor control as well. But a simple UI will be built into the engine as well.
I'm curious though, you say you keep re-compiling the .pde to change parameters? Have you tried the Slim application? It's what I use for testing, and even final shots - it lets you control all parameters in real-time via the serial protocol.
!c
Hi Chris, Have been away for
Hi Chris,
Have been away for a while (I was on a trip to photograph Sharks in the Bahamas) but I am ready to work on the project again.
Is it wise to fork the main engine at this time? It's not on 1.0 yet. Do you think it's possible to include your new functionality in the main branch?
I am trying the new TouchShield code right now; will keep you posted about that. I also have some ideas about powering the motors; that will be a new thread I guess.
To support PWM drivers and
To support PWM drivers and buttons/lcd's, I'm going to need to free up some pins. Primarily, I'm looking to move to SPI for running the stepper drivers later (and support more than 4 steppers), so that would be very different from 0.82 is. I'm working on a 4-driver board with an SPI interface for later. We can then decide if it makes sense to merge the two or fork them. I'm not really won over to one side or the other, but I'd like to keep things stable for those using direct stepper control - if it's not difficult, they could just be code paths in the existing code.
!c
Same issue here. I want to
Same issue here. I want to switch on/off the power of my motors (individually) with the Arduino. I will fit every motor with a separate battery (LiOn of LiPO). It would even be great to monitor the voltage of the batteries. I want to use the Mega for that. Pins are no issue on that board. It's as cheap as a Duemilanove when you buy a clone here. I am working on the electronics to get this to work together with a friend based on fets. Very cheap, but it gets the Arduino in control.
I hope that the code paths in the existing code will do the job. So many ideas, we need more time in a day! I have an advanced controller with a TouchShield and XBee here (just ordered a joystick shield and accelerometer); it only needs some software :-). Tilting the unit should move the motors. The code should be flexible for that. Just buy the toys you want! The basic unit only needs an Arduino and the TouchShield.
Shouldn't we define the v1.0 specs first :-). We can implement all the toys later.
Do you want to start a thread
Do you want to start a thread on a 1.0 concept? We could form a list, set some goals and such =)
The current code path should be fine, I'd like to look into modularizing some parts of it, to make it easier to implement the different concepts, and even toys later *g*
I just finished testing everything that's been implemented so far in 0.82 (plus made/tested some slight changes to the way actions work, as some of the workflow didn't make sense with the repeat cycle), and checked everything in. If you could look through the new docs (added today), and let me know if anything's missing there, or doesn't make sense - that would be very helpful.
!c